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ABSTRACT 


Wireless  networks  can  be  broadly  classified  into  two  types  -  infrastructure  based 
networks  and  ad  hoc  networks.  The  former  uses  fixed  base  stations  (infrastructure)  which 
are  responsible  for  coordinating  communication  between  the  mobile  hosts  (nodes).  These 
base  stations  are  interconnected  by  wired  back  bones,  where  as  mobile  nodes 
communicate  with  the  base  station  through  the  wireless  media.  The  latter  one  consists  of 
mobile  nodes  which  communicate  with  each  other  through  wireless  medium  without  any 
fixed  infrastructure.  Hence  there  is  no  centralized  infrastructure  that  takes  care  of  the 
routing  of  information  among  the  participants  in  the  network.  There  has  been  a  growing 
interest  in  ad  hoc  network  in  recent  years  as  mobile  devices  have  become  more  powerful 
and  are  capable  of  processing  data  like  their  desktop  counterparts.  When  such  a  capability 
is  available  these  devices  should  be  able  to  share  information  among  them  without 
reliance  on  existing  network  infrastructure.  Mobile  devices  are  self  configurable  into 
either  infrastructure  or  ad  hoc  mode.  Protocols  and  software  have  been  developed  to 
enable  mobile  devices  to  connect  to  an  infrastructure  node,  where  as  the  same  is  not  the 
case  in  the  ad  hoc  environment.  Host  mobility  causes  frequent  and  unpredictable 
topological  changes  in  a  wireless  environment.  Finding  and  maintaining  routes  in  ad  hoc 
networks  is  a  non  trivial  task.  This  thesis  will  develop  collaborative  services  in  an  ad  hoc 
(802. 11)  wireless  environment. 
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I.  INTRODUCTION 


A.  BACKGROUND 

Beginning  in  the  early  1990s,  engineers  began  to  develop  a  networking  standard 
that  would  allow  users  freedom  of  movement  by  employing  the  use  of  wireless 
communications.  Today,  that  standard  is  established  and  the  implementation  of  Wireless 
Local  Area  Networks  (WLANs)  is  growing  at  an  almost  exponential  rate. 

Analysts  from  IDC  Technologies  project  that  global  revenue  for  WLAN 
equipment  will  increase  to  $3.72  billion  in  2006  from  $1.45  billion  in  2001  [1],  Most  of 
the  development  has  focused  on  the  ability  to  provide  users  with  the  advantages  of 
increased  mobility,  Convenience  of  use  and  improved  productivity.  The  WLANs  have 
been  built  as  an  extension  of  the  existing  infrastructure  that  provides  the  additional 
facility  of  mobility  to  the  users.  All  this  has  become  possible  with  the  advent  of  small  yet 
powerful  handheld/portable  devices  that  have  the  capability  to  communicate  with  existing 
infrastructure  nodes  in  a  mobile  environment.  However  the  possibility  of  these  devices 
communicating  among  themselves  without  the  use  of  the  infrastructure  nodes  and 
providing  services  has  not  been  exploited  to  its  full  extent.  Such  a  network  wherein  the 
mobile  devices  communicate  among  themselves  without  reliance  on  the  existing 
infrastructure  is  called  an  ad  hoc  network. 

A  wireless  mobile  ad  hoc  network  (MANET)  consists  of  a  collection  of  peer 
mobile  nodes  that  are  capable  of  communicating  with  each  other  with  out  help  from  a 
fixed  infrastructure.  The  inter-connections  between  these  nodes  are  capable  of  changing 
in  a  continuous  and  arbitrary  basis.  Nodes  within  each  other’s  radio  range  communicate 
directly  via  wireless  links  while  those  that  are  far  apart  use  other  nodes  as  relays.  Nodes 
usually  share  the  same  physical  media:  they  transmit  and  acquire  signals  at  the  same 
frequency  band,  and  follow  the  same  hopping  sequence  or  spreading  code.  The  date  link 
layer  function  manages  the  wireless  link  resources  and  coordinates  medium  access 
among  neighboring  nodes.  The  network  layer  function  maintains  the  multi  hop 
communication  path  across  the  network:  all  nodes  must  function  as  routers  that  discover 
and  maintain  routes  to  other  nodes  in  the  network.  Mobility  and  volatility  are  hidden 
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from  the  applications  so  that  any  node  can  communicate  with  any  other  node  as  if 
everyone  were  in  the  fixed  wired  network.  There  are  many  applications  of  ad  hoc 
networks  that  range  from  military  tactical  operations  to  civil  rapid  deployment  such  as 
emergency  search  and  rescue  missions,  data  collection/sensor  network  and  instantaneous 
classroom/meeting  room  applications.  All  these  suggest  that  MANET  is  a  very  complex 
system  which  involves  significant  interactions  across  layers  and  with  the  environment. 

B.  OBJECTIVE 

The  main  objective  of  this  thesis  is  to  implement  collaborative  services  in  an  ad 
hoc  802.11  wireless  network.  There  are  many  routing  protocols  that  have  been  proposed 
for  the  set  up  of  an  ad  hoc  network.  We  will  take  a  look  at  the  proposals  suggested  and 
adapt  one  that  is  implement  able  using  existing  software  classes.  The  devices  that  operate 
in  an  Ad  hoc  network  environment  are  expected  to  be  “aware”  of  other  devices  operating 
in  the  environment  and  also  aware  of  existing  infrastructure  around  them  (if  any).  The 
thesis  shall  develop  an  approach  to  make  devices  “aware”  of  other  devices  and  network 
elements.  Given  the  substantial  benefits  of  WLANS,  it  is  easy  to  understand  why  many 
organizations  are  adopting  this  relatively  new  technology  when  installing  a  new  network 
or  expanding  their  existing  network  infrastructure.  It  is  also  well  published  and  well 
known  that  there  are  denial  of  service  attacks,  hijacking  of  session  attacks  and  many 
more  attacks  possible  against  such  networks  making  them  unavailable  during  certain 
periods  of  time.  The  presence  of  an  ad  hoc  network  during  such  circumstances  capable  of 
providing  communication  among  devices  present  in  the  network  would  help  use  the 
existing  processing  capability  and  deliver  some  useful  collaborative  service  to  one 
another  in  the  network.  The  thesis  will  demonstrate  means  to  successfully  use  the 
processing  capability  available  in  a  network  that  is  degraded  due  to  some  attack  or  in  an 
ad  hoc  network  and  provide  collaborative  services  that  are  required  by  the  user. 


C.  BENEFITS 

The  existence  of  mobile  nodes  that  are  capable  of  communicating  among  them  in 
an  ad  hoc  fashion  increases  the  survival  capacity  of  a  network  which  is  under  hostile 
action.  The  capability  of  the  network  to  adapt  and  transform  itself  also  makes  the  network 
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more  difficult  to  attack.  The  benefits  that  accrue  from  such  a  network  are  many  fold  and 
needs  no  emphasis.  The  ad  hoc  network  elements  would  be  aware  of  the  existence  of 
other  nodes  in  the  environment  and  also  be  able  to  route  traffic  destined  to  other  nodes. 
Such  an  environment  would  allow  multiple  paths  of  communication  as  required. 
However  these  nodes  would  have  to  be  managed  efficiently.  The  requirement  in  such  a 
scenario  would  be  the  efficient  use  of  bandwidth  available  and  the  effective  establishment 
of  routes  from  one  node  to  another  to  carry  infonnation. 


D.  THESIS  ORGANIZATION 

Chapter  II  will  illustrate  the  origin  of  ad  hoc  networking  and  the  techniques 
adapted  in  setting  up  an  ad  hoc  network  using  packet  radios. 

Chapter  III  will  introduce  the  various  wireless  media  access  protocols  that  are 
currently  employed.  The  thesis  will  use  the  existing  IEEE  802.11  standard  in  its 
implementation  and  therefore  discuss  the  employability  of  this  standard  in  an  ad  hoc 
network. 

Chapter  IV  will  introduce  the  various  wireless  Ad-hoc  routing  algorithms  that  are 
evolving  and  being  studied  in  detail.  This  chapter  will  take  a  look  at  the  efficiencies  and 
constraints  of  a  few  of  the  protocols. 

Chapter  V  will  emphasize  the  communication  and  perfonnance  issues. 
Performance  issues  relate  to  energy  efficiency  practices  to  be  adapted  in  an  ad  hoc 
network  so  as  to  compensate  for  deficiencies  in  the  battery  technology  that  have  caught 
up  with  speed  of  development  of  micro-processor  technology. 

Chapter  VI  will  describe  the  software  methodology  followed  to  develop  the 

toolkit. 

Chapter  VII  will  enumerate  the  lesson  leamt  during  the  implementation  of  the 
software  and  will  list  scope  for  future  developments. 
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II.  AD  HOC  NETWORK 


A.  INTRODUCTION 

The  origin  of  an  infrastructure  less  wireless  network  dates  back  to  the  early  70s 
where  computers  and  radio  trans-receivers  were  bulky.  DARPA  had  used  several  wireless 
tenninals  that  could  communicate  with  one  another.  The  communication  was  based  on 
the  transmission  of  packets  using  packet  radio  technology  and  the  concept  of  packet 
switching.  ALOHA  was  another  project  that  was  demonstrated  at  the  University  of 
Hawaii  which  showed  the  feasibility  of  broadcasting  data  packets  in  a  single  radio  hop 
system.  This  single  hop  system  was  later  upgraded  to  a  multi  hop  communication  system 
over  a  wide  geographical  area  and  was  called  the  PRNET.  The  system  consisted  of 
mobile  radio  repeaters,  wireless  terminals  and  dedicated  mobile  stations.  Repeaters 
relayed  packets  from  one  to  another  until  the  packet  reached  the  destination.  Mobile 
stations  acted  as  routers  deriving  routes  for  the  packets  based  on  terminal  movement, 
repeater  failures,  network  congestion  state  and  changes  in  hop  reliability.  Hosts  and 
tenninals  joined  the  PRNET  and  were  unaware  of  their  stations  assignments  and 
reassignment  in  the  network. 


Packet  Radio  Network  (PRN) 


LAN 


Figure  1.  Network  Architecture  of  PRNET.  Static  Station  is  Optional  (From[2]). 
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B.  PRNET  (PACKET  RADIO  NETWORKS  -  ORIGIN  OF  AD  HOC 
NETWORKS) 

Routing  in  PRNET  was  point  to  point  or  broadcast.  Route  calculations  were  based 
on  tables.  There  were  three  tables  that  were  monitored  viz.,  neighbor  table,  tier  table  and 
device  table.  The  neighbor  table  consisted  of  information  regarding  the  existence  of 
another  radio  device  in  its  vicinity.  This  information  was  broadcast  when  a  radio  device 
was  powered  on  in  the  form  of  a  packet  radio  organization  packet  (PROP).  The  PROP 
was  broadcast  every  7.5secs  which  indicated  the  existence  of  other  radio  devices  and  also 
provided  information  about  the  network  topology  at  that  time.  The  bidirectional  quality 
of  the  link  to  and  from  the  neighbors  was  also  stored.  The  link  quality  was  measured  as 
the  number  of  packets  correctly  received  from  a  transmitting  station  during  a  PROP 
interval  to  the  number  of  packets  that  the  station  actually  transmitted  in  the  same  interval. 

Neighboring  PR  Link  Quality 


Node  1 

5/8 

Node  7 

1/3 

Node  3 

3/4 

Node  5 

7/8 

Table  1.  Structure  of  a  Neighbor  Table  in  PRN  (From  [2]). 

The  tier  table  consisted  of  information  regarding  the  best  route  to  be  used  to 
forward  packets  to  every  prospective  destination.  This  infonnation  rippled  outward  from 
each  packet  radio  at  an  average  of  3.75secs.  The  best  route  was  considered  the  shortest 
route  with  good  connectivity.  When  a  link  turned  bad,  all  routes  using  the  link  as  the  next 
hop  were  marked  bad  and  this  was  also  propagated  via  PROPS. 
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Destination  PR  Next  Hop  PR  Tier  Count 


Node  1  Node  15  2 

Node  7  Node  7  0 

Node  3  Node  4  1 

Node  5  Node  2  1 


Table  2.  Structure  of  Tier  Table  in  PRN  (From[2]). 


The  device  table  was  used  to  maintain  device  to  packet  radio  mapping.  Each 
mobile  device  or  tenninal  periodically  sent  control  packets  across  the  wired  interface  to 
its  attached  packet  radio  and  this  infonnation  was  broadcast  at  an  average  rate  of  3.75secs 
per  hop. 

The  (ETE-  end  to  end)  header  used  to  transmit  the  radio  packets  included  the 
source  device  ID/address  and  the  destination  device  ID/address.  This  infonnation 
remained  intact  as  the  packet  moved  from  the  source  to  its  destination.  In  contrast  to  this 
header  (ETE),  another  header  called  the  routing  header  was  created  by  the  source  packet 
radio.  This  header  encapsulated  the  ETE  header  (which  had  to  remain  intact  through  out 
the  packets  journey)  with  relevant  next  hop  infonnation  and  acknowledgement  fields. 
These  fields  were  updated  by  the  intennediate  radio  elements  until  the  packet  was 
successfully  delivered.  When  delivered  the  routing  header  was  discarded. 
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Routing  Header  Field 

Source  PR  ID 
Sequence  Number 
Previous  PR  ID 
Previous  PR’s  transmit  count 
Transmitting  PR  ID 
Transmitting  PR’s  transmit  count 
Next  PR  ID 
Tier 

Destination  PR  ID 


Purpose 

Acknowledgement 

Acknowledgement 

Acknowledgement 

Pacing 

Acknowledgement 

Pacing 

Acknowledgement/Forwarding-Pacing 
Alternate  Routing 
Forwarding 


Table  3.  Structure  of  Routing  Header  (From[2]). 


The  time  for  transmission  of  these  packets  was  based  on  a  pacing  protocol  that 
provided  flow  and  congestion  control.  The  protocol  required  that  transmitted  packets  be 
acknowledged  before  subsequent  packets  are  sent.  In  addition  only  two  buffers  were 
provided  per  packet  radio  to  accept  packages  received  from  the  wired  interface.  Time 
delays  were  recorded  between  when  a  transmission  is  completed  and  the  reception  of  the 
acknowledgement  from  the  next  packet  radio.  This  was  called  the  forwarding  delay. 
Therefore  the  source  packet  radio  had  to  wait  for  a  three  frame  period  in  order  to  confirm 
that  its  packet  had  been  sent,  received  at  the  intermediate  node  and  then  get 
acknowledgement  of  the  forwarding  of  the  same  packet  by  the  intermediate  node.  This 
ensured  efficient  use  of  the  channel  when  there  is  no  bottle  neck  and  provided  some 
congestion  control  when  bottle  necks  were  experienced. 

Packet  radios  employed  CSMA  (carrier  sense  multiple  access)  for  media  access. 
The  packet  radio  will  not  transmit  when  a  carrier  is  sensed  as  this  indicates  transmission 
by  another  packet  radio.  Packets  are  forwarded  in  a  single  communication  route.  Each 
packet  radio  decides  whether  it  is  part  of  the  route  and  transmits/forwards  the  packet  only 
if  it  is  and  discards  the  packet  if  it  isn’t.  If  the  packet  radio  is  part  of  the  route  then  it 
forwards  the  packet  and  also  provides  a  “passive”  acknowledgement  of  the  same  to  its 
previous  hop.  This  continues  until  the  packet  is  received  at  the  node  which  does  not  have 
a  downstream  node  or  the  destination  which  then  does  an  “active”  acknowledgement. 
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PR2 


PR3 


device  A 


PR1 
(source 
packet  radio) 


I 


i 


PR4 

(destination 
packet  radio) 


Device  B 


Figure  2.  Passive  and  Active  Acknowledgements  in  PRNET  (From[2]). 


C.  AD  HOC  NETWORK  CHALLENGES 

Ad  hoc  wireless  networks  are  fonned  by  a  collection  of  two  or  more  devices  that 
have  the  capability  of  wireless  communication  and  networking.  The  ad  hoc  network  in 
itself  is  self  organizing  and  adaptive.  Thereby  these  networks  can  be  mobile,  work  in  a 
stand  alone  mode  or  be  networked  with  more  than  two  elements.  In  addition  there  may  be 
concurrent  movement  by  the  nodes.  This  will  require  rules  to  ensure  consistency  when 
multiple  route  reconfiguration  and  repair  is  performed. 

1,  Spectrum  Allocation 

Ad  hoc  networks  are  based  on  the  ISM  band  and  are  required  to  operate  over 
some  form  of  allowed  frequency  range.  The  spectrum  is  not  only  tightly  controlled  and 
allocated  but  may  be  required  to  be  purchased  in  the  future. 
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2.  Media  Access 

Cellular  networks  have  a  centralized  control  and  a  global  synchronization.  There 
are  no  such  controls  in  an  ad  hoc  network.  Therefore  the  schemes  that  are  used  in  a 
cellular  network  (TDMA,  FDMA)  are  not  suitable  in  ad  hoc  networks.  Other  media 
access  control  MAC  protocols  do  not  deal  with  host  mobility.  In  ad  hoc  networks  we 
have  to  deal  with  multiple  mobile  ad  hoc  nodes  or  hosts  that  have  access  to  the  common 
channel  and  must  share  the  channel  without  a  central  coordination  mechanism  in  a 
distributed  fashion.  Therefore  the  MAC  protocol  that  is  designed  for  ad  hoc  network  must 
contend  with  problems  such  as  collision  with  neighboring  nodes,  hidden  terminal 
problems  and  exposed  node  problems.  These  problems  and  the  mechanism  to  overcome 
them  are  discussed  in  the  chapter  2  of  the  thesis. 


3.  Routing 

The  classical  distributed  Bellman-Ford  routing  algorithm  is  used  to  maintain  and 
update  routing  information  in  a  packet  radio  network.  Distance-vector  based  algorithms 
could  also  be  used  in  a  packet  radio  network  because  the  rate  of  mobility  in  this  network 
is  not  high.  However  these  protocols  will  not  support  a  truly  ad  hoc  network  as  the 
presence  of  mobility  implies  that  links  make  and  break  in  a  nondetenninistic  fashion. 
Therefore  the  current  distance-vector  and  link  state  based  routing  protocols  do  not  have 
the  capability  to  address  frequent  link  changes  in  ad  hoc  networks  resulting  in  improper 
route  convergence  and  inefficient  communication  throughput.  Therefore  new  routing 
algorithms  are  needed.  We  will  take  a  look  at  a  few  routing  algorithms  and  list  their 
advantages  and  disadvantages  in  chapter  3  of  the  thesis. 

4.  Energy  Efficiency 

All  known  network  protocols  do  not  consider  power  requirements  as  they  are 
meant  for  static  hosts  and  routers  which  are  powered  by  mains.  However  in  the  ad  hoc 
scenario  all  the  devices  are  mobile  and  are  generally  powered  by  batteries.  These  mobile 
devices  have  a  superior  micro  processor  technology  and  are  able  to  process  and  compute 
enonnous  information.  However  the  battery  technology  has  not  evolved  sufficiently  to 
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provide  unlimited  power  for  these  devices.  Therefore  energy/power  consumption  is  a 
major  design  consideration  in  an  ad  hoc  network.  In  particular  nodes  in  an  ad  hoc  mobile 
network  require  performing  both  the  role  of  an  end  user  system  (user  interacting  system) 
and  an  intermediary  system  (packet  forwarding  system).  Forwarding  packets  on  behalf  of 
others  consumes  power  and  thereby  routing  protocols  have  to  consider  energy  efficiency 
requirements  under  such  circumstances.  These  requirements  and  other  communication 
requirements  are  discussed  in  chapter  4  of  the  thesis. 


5.  Security  and  Privacy 

Ad  hoc  networks  are  generally  isolated  from  the  internet  unless  they  are 
connected  to  the  internet  through  a  wired  node.  Therefore  the  attacks  possible  are  limited 
to  attackers  in  the  physically  proximity/  radio  range  of  the  network.  However  the  attacker 
does  not  require  any  physical  connectivity  to  the  network  to  perform  any  malicious  acts 
and  this  makes  spoofing,  passive  monitoring,  active  jamming,  interception/relaying  of 
packets,  session  hijacking  etc  easier  than  in  a  wired  environment.  This  requires  a  good 
neighbor  node  and  user  authentication  mechanism,  sound  encryption  and  a  sound  session 
management  system. 

6.  Congestion  Control  Mechanism 

TCP  is  a  connection  oriented  protocol  most  widely  used  to  provide  for  flow  and 
congestion  in  a  wired  network.  This  protocol  relies  on  the  round  trip  time  of  a  packet  to 
conclude  if  congestion  has  occurred.  In  an  ad  hoc  network  such  a  mechanism  will  be 
unable  to  distinguish  network  congestion  as  packets  may  be  lost  or  dropped  because  of 
the  nature  of  the  wireless  medium.  Therefore  certain  suitable  modifications  or 
enhancements  have  to  be  made  to  the  existing  TCP  protocol  so  as  to  enable  TCP  support 
effective  end  to  end  communication  throughput  in  a  wireless  environment. 
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III.  MEDIA  ACCESS  CONTROL 


A.  INTRODUCTION 

Wireless  media  can  be  accessed  by  any  node  in  a  shared  environment.  This  could 
lead  to  possible  contention  over  this  common  channel.  In  an  ad-hoc  network  the  problems 
are  compounded  as  the  nodes  are  mobile  and  there  is  no  central  controller.  We  will  take  a 
look  at  the  existing  protocols  that  allow  efficient  use  of  a  shared  wireless  media.  The  first 
protocol  is  the  MAC  protocol  which  is  concerned  with  a  single  link  communication  and 
not  an  end  to  end  communication.  There  are  two  types  of  MAC  protocols  synchronous 
and  asynchronous.  Synchronous  MAC  protocol  requires  all  nodes  be  synchronized  in 
time  and  this  is  achieved  by  synchronizing  to  a  master  beacon.  Therefore  this  requires 
central  coordination.  Asynchronous  MAC  protocol  does  not  necessarily  follow  the  same 
time  and  are  contention  based. 

B.  HIDDEN  TERMINAL  PROBLEM 

Well  know  protocols  such  as  ALOHA,  slotted  ALOHA,  CSMA,  IEEE  802.11 
have  a  common  problem  known  as  the  hidden  terminal  problem.  When  two  nodes  are 
hidden  from  each  other  (beyond  radio  range)  they  can  start  transmitting  simultaneously 
thereby  resulting  in  a  collision  of  data  at  the  receiver  node.  To  avoid  collision  a  process 
of  hand  shaking  with  the  help  of  control  signals  such  as  RTS  (request  to  send)  and  CTS 
(clear  to  send)  were  used  and  a  new  protocol  developed.  This  protocol  required  nodes  not 
to  access  the  medium  when  an  RTS  was  sent  and  a  CTS  was  generated  to  acknowledge 
the  RTS.  The  RTS  and  CTS  signals  consisted  of  a  field  that  showed  the  time  duration  for 
which  the  channel  is  to  be  considered  busy.  This  method  also  had  its  problems  known  as 
the  hidden  terminal  problem.  The  hidden  terminal  problem  occurs  when  RTS  and  CTS 
control  messages  are  sent  by  different  nodes.  For  example,  node  B  is  granting  a  CTS 
signal  to  a  node  A  which  collides  with  the  RTS  signal  being  sent  by  node  D  to  another 
node  C.  Node  D  is  the  hidden  tenninal  from  node  B  and  it  does  not  receive  the  expected 
CTS  from  node  C.  This  causes  a  retransmission  of  the  RTS  by  node  D  for  node  C.  Node 
A  would  have  received  the  CTS  from  node  B  and  is  not  aware  of  any  collision  that  exists 
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at  node  C  and  hence  proceeds  with  the  transmission  of  data  to  node  B.  Under  these 
circumstances  the  data  would  collide  with  the  CTS  being  sent  by  node  C  in  response  to 
the  RTS  sent  by  node  D. 


Figure  3.  Hidden  Tenninal  Problem  (From  [2]). 

Another  problem  could  occur  when  multiple  CTS  messages  are  granted  to 
different  neighboring  nodes  leading  to  collisions.  For  example,  when  node  B  returns  a 
CTS  message  in  response  to  an  RTS  message  sent  by  node  A  and  node  C  sends  an  RTS 
message  at  the  same  time  to  node  B.  Node  C  is  unaware  of  the  communication  between 
node  A  and  B  and  also  sends  an  RTS  to  node  D.  Node  D  proceeds  to  grant  CTS  message 
to  node  C.  Under  this  scenario  both  nodes  A  and  C  start  transmitting  data  leading  to  a 
collision. 
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3.  A  sends  its  data  to  B.  4.  B  acknowledges  the  data  transfer. 

C  is  blocked  from  transmitting. 


Figure  4.  Hidden  Node  Problem  Resolution  by  RTS-CTS  Handshake  (From  [2]). 

C.  EXPOSED  NODE  PROBLEM 

Data  transmissions  occurring  from  neighboring  nodes  will  inhibit  one  node  from 
transmitting  to  other  nodes  as  the  node  overhears  the  transmission.  This  is  called  an 
exposed  node  problem.  A  node  in  range  of  the  transmitter  but  out  of  range  of  the  receiver 
is  called  an  exposed  node.  Under  such  conditions  the  exposed  node  tries  communicating 
without  success  and  also  inhibits  other  nodes  from  communicating  successfully.  The  use 
of  a  separate  control  and  data  channel  or  the  use  of  directional  antenna  would  eliminate 
this  problem. 
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•  C  is  transmitting  to  D. 

•  B  overhears  this,  and  is  blocked. 

•  B  wants  to  transmit  to  A,  but  is  being 
blocked  by  C. 

•  Wasted  bandwidth! 


Figure  5.  Exposed  Node  Problem  (From  [2]). 


Directional  antenna  reduces  this  problem!  B  is  not  blocked  from  sending  to  A. 


Figure  6.  Solution  of  Exposed  Node  Problem  by  Unidirectional  Antennae  (From  [2]). 


16 


D.  CSMA-CD 

The  multiple  access  collision  avoidance  (CSMA-CA)  technique  is  dependant  on  a 
three  way  hand  shake,  RTS-DTS-DATA.  The  main  feature  of  this  protocol  is  that  it 
inhibits  a  transmitter  when  a  CTS  packet  is  overheard.  Thereby  collision  does  not  occur 
even  during  the  RTS-CTS  phase.  The  mobile  hosts  add  a  random  amount  of  time  to  the 
minimum  interval  required  waiting  after  an  RTS  or  CTS  control  message  is  sent.  If  two 
or  more  stations  transmit  an  RTS  concurrently  resulting  in  a  collision,  these  stations  will 
wait  for  a  randomly  chosen  interval  before  trying  again.  This  interval  is  doubled  if  there 
is  a  collision  on  every  attempt  thereafter.  The  station  that  succeeds  will  receive  CTS  from 
its  responder  and  thereby  block  other  stations  from  transmitting  to  allow  the  data 
communication  session  to  begin. 


Figure  7.  Controlled  Handshake  used  in  CSMA-CA  (From  [2]). 
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E.  CSMA-CD-BI 

There  is  another  multiple  access  collision  avoidance  mechanism  (CSMA-CA-BI) 
which  uses  only  a  two  way  handshake.  In  this  case  there  is  no  RTS  instead  the  message  is 
reconfigured  as  RTR  (ready  to  receive).  This  mechanism  is  called  multiple  access 
collision  avoidance  by  invitation.  The  RTR  is  sent  when  the  receiver  node  is  ready  to 
accept  data.  In  this  scenario  the  receiver  does  not  necessarily  know  that  the  sender  has 
data  to  transmit.  The  communication  performance  in  this  protocol  is  dependant  on  the 
timely  invitation  sent  by  the  receiver.  This  time  period  is  estimated  based  on  the  packet 
queue  length  and  arrival  rate  at  the  source.  This  is  accomplished  by  sending  the  packet 
queue  length  and  arrival  rate  information  along  with  each  data  packet  so  as  to  enable  the 
receiver  is  aware  of  the  transmitter’s  backlog.  This  scheme  is  successful  when  the  data 
rate  is  constant  and  the  performance  drops  when  the  traffic  comes  in  bursts.  In  the  worst 
case  scenario  this  mechanism  will  perfonn  no  better  than  the  multiple  access  collision 
avoidance  case. 


Figure  8.  CSMA-CA  BI  Handshake  (From  [2]). 


F.  PAMAS 

The  power  aware  multiple  access  protocol  with  signaling  (PAMAS)  is  used  in  ad 
hoc  networks  and  is  based  on  the  CSMA-CA  with  the  additional  signaling  channel.  This 
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protocol  requires  the  conservation  of  battery  power  by  selectively  powering  off  non 
active  nodes  or  nodes  not  receiving  any  package.  Conditions  that  force  a  node  to  power 
off  mode  are: 

i.  Node  has  no  packets  to  transmit  and  one  of  its  neighbors  is  transmitting. 

ii.  A  node  has  packets  to  transmit  but  at  least  one  of  its  neighboring  nodes  is 
transmitting  or  is  receiving. 

Suppose  a  node  A  wishes  to  transmit,  it  sends  an  RTS  and  enters  a  wait-for-CTS 
state.  If  the  CTS  does  not  arrive  the  node  takes  an  exponential  back  off  state  and  retries 
to  send  the  RTS  later.  If  the  CTS  arrives  node  A  enters  transmit  data  state.  The  receiver 
node  B  sends  a  CTS  and  enters  the  await  data  state.  If  the  data  arrives  the  node  will 
transmit  a  busy  tone  over  the  signaling  channel  and  enter  receive  data  state. 


On/Off  Power  Transmit 

Queue 


Figure  9.  PAMAS  MAC  interfaces  and  Power  Aware  Logic  (From  [2]). 


G.  DBTMA 

DBTMA  (dual  busy  tone  multiple  access)  uses  two  out  of  band  busy  tones  and  a 
single  shared  channel  split  into  data  and  control  channels.  Data  packets  are  sent  over  the 
data  channel  and  the  control  signals  over  the  same  shared  channel.  When  a  station 
wants  to  transmit  it  first  sends  out  an  RTS  message.  The  receiver  node  willing  to  accept 
the  data  sends  out  a  receive-busy  tone  followed  by  CTS  message.  Upon  receiving  this 
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CTS  message,  the  source  transmits  a  busy  tone  message  prior  to  data  transmission. 
Neighboring  nodes  that  hear  transmit  busy  refrain  from  transmission  and  discard  any 
received  packets. 


Node  A 
(Source) 

RTS~ 

CTS 

, 

Data 

U- - 

' - ^ - 7* 

Node  B 
(Receiver) 


Data 


Transmit  Busy  Tone 
of  Node  A 


Receive  Busy  Tone 
of  Node  B 


Figure  10.  DBTMA  Principle  (From  [2]). 


H.  MARCH 

MARCH  (media  access  with  reduced  handshake)  improves  the  transmission  of 
packets  by  reducing  the  amount  of  control  overhead.  It  uses  the  characteristics  of  omni 
directional  antenna  to  reduce  the  required  number  of  handshake  signals.  Adjacent  nodes 
B  and  C  in  a  route  will  be  able  to  monitor  the  CTS  signal  transmitted  by  the  node  B  to 
its  source  node  A.  Thereby  node  C  can  send  CTS  to  node  B  without  a  RTS  and  the  data 
can  be  forwarded  from  the  node  B  to  C  for  onward  transmission.  This  is  illustrated  in 
the  figure  below.  This  protocol  is  a  request  first  pull  later  protocol  as  the  subsequent 
nodes  in  the  path  just  need  to  send  invitation  to  pull  data  towards  them. 
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•  •  • 


Figure  1 1 .  Handshake  mechanism  of  MARCH  (From  [2]). 

I.  IEEE  802.11  STANDARD 

IEEE  802.11  standard  supports  a  peer  to  peer  (IBSS)  independent  basic  service 

set  which  is  an  ad  hoc  network  with  all  its  station  within  each  others  transmission  range. 

Hence  this  technology  becomes  the  obvious  choice  when  setting  up  an  ad  hoc  network. 

Let  us  take  a  look  at  the  evolution  of  this  standard.  IEEE,  European  Telecommunication 

Standards  Institute  and  One  Technology  Alliance  (Home  RF)  promote  wireless  local  area 

network  standards  (WLAN).  Among  the  standards  that  were  instituted  by  these 

organizations  the  leading  standard  was  the  IEEE  802.11  standard.  Among  the  IEEE 

802.11  standards,  802.11b  (Wi-Fi)  was  the  leader.  802.11a  and  802. 1 1  g  were  the 

challengers  to  this  standard.  802.11b  is  based  on  the  (DSSS)  direct  sequence  spread 

spectrum  version  of  802.1 1  using  a  2.4  GHz  spectrum  and  orthogonal  frequency  division 

multiplexing  (OFDM).  Its  counterpart  802.11a  uses  the  5GHz  spectrum.  The  2.4GHz 

spectrum  is  capable  of  penetrating  physical  barriers  such  as  walls  and  ceilings  and  is 

unlicensed  in  most  of  the  countries.  802.11b  supports  a  raw  data  transfer  rate  of  1 1Mbps 

up  to  a  distance  of  30meters.  The  rate  drops  to  5.5Mbps  beyond  30  meters  and  drops  to 
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2Mbps  around  65meters.  The  maximum  range  is  lOOmeters  and  the  data  rate  is  1Mbps. 
The  interesting  point  about  the  802.11b  specification  is  that  it  supports  roaming  between 
access  points.  The  specification  requires  a  method  for  roaming  but  leaves  the 
implementation  to  the  manufacturer.  A  feature  known  as  the  wired  equivalent  privacy 
(WEP)  was  created  with  the  802.11  specification  to  provide  security.  The  intention  was 
to  provide  a  basic  level  of  authentication  and  privacy  by  the  use  of  data  encryption.  For 
authentication  an  access  point  will  request  a  client  to  verify  its  identity  by  sending  a  text. 
The  client  will  use  RC4  encryption  with  a  secret  key  to  encrypt  the  text  and  return  it  back 
to  the  access  point.  The  access  point  will  then  decrypt  the  text  using  the  same  key  and 
verify  whether  the  client  is  to  be  granted  access  or  not.  The  WEP  consists  of  a  24bit 
initialization  vector  in  addition  to  the  WEP  key.  This  vector  is  changed  after  a  certain 
interval.  However  this  initialization  vector  is  sent  in  the  clear  and  thereby  the  WEP 
security  is  not  very  strong.  Additional  security  mechanisms  are  being  incorporated  into 
this  standard  by  a  task  group  and  the  new  standard  draft  is  currently  being  named  as  the 
802.1  li  standard. 

Synchronization  is  necessary  for  frequency  hopping  spread  spectrum  (FHSS)  to 
ensure  that  all  stations  “hop”  at  the  same  time:  it  is  also  necessary  for  both  FHSS  and 
DSSS  to  perform  power  management.  In  an  IBSS  that  is  not  very  small  there  is  a  non 
negligible  probability  that  the  stations  may  get  out  of  synchronization.  As  the  number  of 
stations  increase,  the  probability  of  asynchronism  also  increases.  To  alleviate  this 
problem  modifications  have  been  suggested  to  the  current  synchronization  algorithm  of 
the  802.11  standard.  Therefore  the  IEEE  802.11  IBSS  is  a  fully  connected  single  hop  ad 
hoc  network  with  all  station  within  each  others  range.  Investigations  are  currently  being 
done  to  see  if  the  802.1 1  standard  can  support  multi  hop  ad  hoc  networks  assuming  each 
station  has  the  capability  of  routing. 
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IV.  AD  HOC  ROUTING  PROTOCOLS 


A  OVERVIEW 

Since  the  advent  of  packet  radio  networks  in  the  early  70’s  by  DARPA  numerous 
protocols  have  been  developed  for  ad  hoc  mobile  networks.  All  these  protocols  require 
dealing  with  power  consumption,  low  bandwidth  and  high  error  rates.  These  protocols 
can  be  characterized  as: 

i)  Table  driven 

ii)  Source  initiated  on  demand  driven 

The  table  driven  approach  attempts  to  maintain  consistent,  up  to  date  infonnation 
for  each  node  to  every  other  node  in  the  network  using  tables.  They  respond  to  changes  in 
the  network  by  updating  the  required  information  and  also  propagating  route  updates  to 
maintain  a  consistent  view.  The  source  initiated  on  demand  approach  creates  routes  only 
when  desired  by  a  source  node.  When  the  node  requires  a  route  to  a  destination  a 
discovery  process  is  initiated  and  is  completed  once  a  route  is  found.  The  process 
examines  all  possible  permutations  before  suggesting  a  route.  Once  the  route  is 
discovered  it  is  maintained  by  a  route  maintenance  procedure.  If  the  route  becomes 
inaccessible  or  is  no  longer  desired,  it  is  dropped  by  the  maintenance  procedure. 


Figure  12.  Types  of  AD  HOC  Routing  Protocol  (From  [2]). 
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B  TABLE  DRIVEN  APPROACHES 

The  table  driven  approaches  are  - 

1.  Destination  Sequenced  Distance  Vector  (DSDV) 

This  protocol  is  based  on  the  classical  distributed  Bellman-Ford  algorithm. 
However  loops  are  avoided  in  this  algorithm  by  the  use  of  routers.  Every  node  maintains 
the  route  information  in  a  table  of  all  the  possible  destinations  within  a  non-partition 
network  and  the  number  of  hops  to  each  destination  if  required.  Therefore  the  route  is 
always  available  regardless  of  whether  it  is  required  or  not.  Routes  are  distinguished  by 
providing  a  sequence  number.  Updates  are  done  periodically  through  out  the  network  to 
maintain  consistency  and  this  rendering  causes  a  lot  of  control  traffic  which  reduces  the 
utilization  of  network  resources.  To  alleviate  this  problem  route  updates  are  performed 
using  one  of  the  two  route  update  packets.  The  first  known  as  full  dump  is  performed 
infrequently  when  there  is  less  traffic  and  this  packet  consists  of  all  available  routing 
information.  This  information  is  sent  in  multiple  network  protocol  data  units.  The  second 
known  as  incremental  packets  are  used  to  relay  only  changes  since  the  last  full  dump. 
Broadcasts  containing  new  route  information  will  consist  of  the  address  of  the 
destination,  the  number  of  hops  to  reach  the  destination,  a  sequence  number  of  the 
information  received  regarding  the  destination  as  well  as  a  new  sequence  number  unique 
to  the  broadcast.  The  route  labeled  with  the  most  recent  sequence  number  (in  increasing 
order)  is  always  used  and  the  route  with  the  smaller  hop  count  is  used  in  case  the 
sequence  number  is  the  same  for  more  than  one  route. 

2.  Wireless  Routing  Protocol  (WRP) 

Wireless  routing  protocol  belongs  to  a  family  of  path  finding  algorithms  which 
avoid  loops.  In  this  algorithm  the  nodes  communicate  information  regarding  the  distance 
and  the  second-to-last  hop  in  the  network.  This  algorithm  avoids  the  count  to  infinity 
problem  caused  by  loops  by  forcing  every  node  in  the  network  to  perfonn  consistency 
checks  of  predecessor  information  reported  by  all  its  neighbors.  This  process  avoids 
looping  situations  and  also  provides  an  efficient  route  convergence  when  a  link  failure 

happens.  The  existence  of  nodes  is  informed  by  the  neighbors  acknowledging  the  receipt 
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of  transmitted  requests  and  other  messages.  When  a  node  is  not  sending  any  packets  it 
must  send  a  hello  message  within  a  specific  period  of  time  that  informs  that  the  node  is 
properly  connected.  If  there  is  a  lack  of  message  from  a  particular  node  then  it  indicates  a 
link  failure.  When  a  hello  message  is  received  that  new  node  information  is  added  to  the 
routing  table  and  a  copy  of  this  table  is  sent  to  its  neighbors. 

WRP  maintains  four  tables  viz.,  a)  Distance  table  b)  Routing  table  c)  Link  cost 
table  and  d)  Message  retransmission  list.  The  number  of  hops  between  a  node  and  its 
destination  is  stored  in  the  distance  table.  The  next  hop  information  is  stored  in  the 
routing  table.  The  delay  infonnation  associated  is  stored  in  the  link  cost  table.  Sequence 
number  of  the  update  message,  a  retransmission  counter,  an  acknowledgement  required 
flag  vector  and  a  list  of  update  messages  sent  are  stored  in  the  message  retransmission 
list.  Retransmitted  messages  must  be  acknowledged  by  the  neighbors  and  such 
information  is  stored  as  updates  in  the  update  message  of  the  MRL. 

3.  Cluster  Gateway  Switch  Routing  (CGSR) 

In  this  form  of  routing  nodes  are  grouped  into  clusters  with  every  cluster  having  a 
head.  Such  a  grouping  introduces  a  fonn  of  hierarchy.  The  cluster  head  controls  the  group 
and  this  framework  provides  for  code  separation,  channel  access,  routing  and  bandwidth 
allocation.  The  cluster  head  is  chosen  using  a  distributed  cluster  head  selection  algorithm. 
When  a  cluster  head  leaves  the  group  a  new  head  is  selected.  This  could  lead  to  problems 
if  the  cluster  head  changes  frequently  as  the  group  will  then  spend  time  choosing  a  new 
cluster  head  instead  of  forwarding  data  towards  their  intended  destinations.  To  avoid  this 
phenomenon  a  least  cluster  change  (LCC)  algorithm  is  introduced.  This  algorithm  effects 
a  change  only  when  two  cluster  heads  come  into  contact  or  when  a  node  moves  out  of  all 
other  cluster  heads.  CSGR  basically  employs  the  DSDV  routing  scheme  with  a  slight 
modification.  The  modification  involves  the  use  of  cluster-head-to-gateway  routing 
approach  to  send  packages  from  the  source  to  its  destination.  Nodes  that  are  within 
communication  range  of  two  or  more  cluster  heads  are  called  gateway  nodes.  A  packet 
sent  by  a  node  is  first  routed  to  its  cluster  head  and  then  through  a  gateway  it  is  routed  to 
the  cluster  head  of  the  destination  node.  Once  the  destination  node  cluster  head  is  reached 

the  packet  is  then  transmitted  to  the  destination.  Therefore  each  node  must  keep  a  cluster 
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member  table.  This  table  information  is  broadcast  by  every  node  using  the  DSDV 
protocol  periodically.  In  addition  a  routing  table  is  also  maintained  to  keep  track  of  the 
next  hop  information.  When  a  packet  arrives,  the  next  hop  information  and  the  cluster 
member  information  of  the  nearest  cluster  head  along  the  route  is  processed  and  the 
message  is  transmitted.  Update  information  regarding  both  routing  and  cluster  member 
tables  is  needed  in  the  CSGR  approach. 


Figure  13.  CGR  path  constrained  into  cluster  heads  (From  [2]). 

C.  SOURCE  INITIATED  ON  DEMAND  APPROACHES 

The  source  initiated  on  demand  approaches  are  - 

1.  Ad  Hoc  on  Demand  Distance  Vector  Routing  (AODV) 

The  AODV  protocol  is  an  improvement  of  the  DSDV  approach  as  it  minimizes 
the  number  of  required  broadcast  by  generating  the  routes  on  an  on  demand  basis  as 
apposed  to  maintaining  the  complete  list  of  routes.  Routes  that  are  not  the  selected  path 
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do  not  maintain  any  routing  information  and  do  not  participate  in  any  exchange  of  any 
routing  table  information.  Messages  sent  to  a  destination  by  a  source  generate  a  path 
discovery  process  when  a  valid  route  to  the  destination  does  not  exist.  When  a  source 
node  has  to  send  a  message  it  broadcasts  a  route  request  packet  (RREQ)  to  all  its 
neighbors  which  is  then  forwarded  by  the  neighbors  to  their  neighbors  and  so  on  until  the 
destination  is  reached  or  an  intermediate  node  with  a  recently  updated  route  to  the 
destination  is  located.  AODV  maintains  destination  sequence  numbers  and  recent  route 
information  to  all  nodes  which  ensures  the  routes  are  loop  free.  Every  node  has  a 
broadcast  ID  and  a  sequence  number.  The  broadcast  ID  together  with  the  nodes  IP 
address  uniquely  identifies  an  RREQ  which  is  incremented  every  time  a  path  discovery 
process  is  initiated.  A  message  containing  the  sequence  number,  broadcast  id  and  the 
most  recent  RREQ  is  sent  when  the  source  node  requires  communicating  with  the 
destination.  Intennediary  nodes  reply  to  the  RREQ  only  if  there  is  a  route  to  the 
destination  whose  corresponding  destination  sequence  number  is  greater  than  or  equal  to 
that  contained  in  the  RREQ.  Intermediary  nodes  record  in  their  route  tables  the  address  of 
the  neighbors  from  which  the  first  copy  of  broadcast  packet  was  received  when  they 
forward  the  RREQ  and  thereby  establish  a  reverse  path.  If  multiple  copies  of  the  same 
RREQ  are  received  they  are  discarded.  When  the  destination  is  reached,  the  destination 
or  an  intermediary  node  responds  by  sending  a  route  reply  (RREP)  along  the  reverse 
path.  As  the  RREP  is  routed  back  along  the  reverse  path  intennediary  nodes  in  this  path 
set  up  route  entries  in  their  table  that  point  to  the  node  from  which  the  RREP  was 
received.  These  route  entries  indicate  the  active  forward  path.  Every  route  entry  is 
associated  with  a  timer  and  is  deleted  if  the  entry  is  not  used  within  the  specified  life 
time.  When  a  source  node  moves  it  has  to  reinitiate  the  discovery  process  to  find  a  new 
route  to  the  destination.  If  an  intermediary  node  along  the  route  moves  then  its  upstream 
neighbor  propagates  a  link  failure  notification  message  (RREP  with  infinite  cost)  to  each 
of  its  active  upstream  neighbors  and  requires  them  to  erase  that  part  of  the  route 
information.  This  notification  is  further  propagated  by  the  upstream  neighbors  to  their 
active  upstream  neighbors  and  so  on.  Hello  messages  are  periodic  local  broadcasts  made 
by  a  node  to  inform  its  presence  to  its  neighbors  may  be  additionally  used  to  indicate  the 
existence  of  a  link.  However  the  use  of  these  messages  is  not  required  as  the  nodes  listen 
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for  retransmissions  of  data  packets  and  if  such  a  retransmission  is  not  heard  the  node 
assumes  a  link  failure.  It  may  then  request  acknowledgement  for  network  connectivity 
using  the  hello  messages  or  any  other  message. 
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Figure  14.  AODV  route  discovery  process  (From  [2]). 


2.  Dynamic  Source  Routing  (DSR) 

Dynamic  source  routing  is  based  on  the  concept  of  source  routing.  In  this  routing 
nodes  are  required  to  maintain  route  caches  that  contain  routes  which  the  nodes  are  aware 
of.  Entries  are  continually  updated  into  the  route  cache  as  new  routes  are  discovered.  The 
protocol  consists  of  two  major  processes  a)  route  discovery  and  b)  route  maintenance. 
When  a  packet  is  available  at  a  source  node  for  dispatch  for  some  destination,  the  source 
node  first  consults  its  route  cache  to  determine  if  there  exists  an  unexpired  route  to  that 
destination.  If  such  a  route  exists  the  packet  is  sent  using  that  route  and  if  it  doesn’t  a 
route  discovery  process  is  initiated  by  broadcasting  a  route  request  packet.  The  route 
request  message  consists  of  the  address  of  the  destination  along  with  the  address  of  the 
source  node  and  a  unique  ID.  Each  node  receiving  this  route  request  message  checks  its 
cache  to  see  if  a  route  to  the  destination  exists  before  forwarding  the  message  along  its 
outgoing  links.  To  limit  the  outward  propagation  of  route  requests  a  mobile  node 
forwards  the  route  request  only  if  the  request  has  not  been  seen  so  far  or  the  mobile’s 
address  has  not  appeared  in  the  route  record.  A  route  reply  is  generated  when  the  route 
request  reaches  the  destination  or  an  intennediary  node  which  has  an  unexpired  route  to 
the  destination  on  its  cache.  The  route  reply  specifies  the  route  from  the  source  to  the 
destination.  Route  maintenance  is  done  by  the  use  of  a  route  error  packet  and 
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acknowledgements.  Route  errors  are  generated  when  there  is  a  fatal  transmission 
problem.  Route  error  messages  are  also  used  to  verify  the  proper  functioning  of  the  route 
links.  Acknowledgements  to  route  error  messages  could  also  be  passive 
acknowledgements . 
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Figure  15.  DSR  source  route  creation  process  (From  [2]). 


3.  Temporally  Ordered  Routing  Algorithm  (TORA) 

TORA  is  based  on  the  concept  of  link  reversal  which  is  a  highly  adaptive  loop 
free  distributed  routing  algorithm.  The  most  essential  requirement  of  a  TORA  is  the 
localization  of  control  messages  to  a  very  small  set  of  nodes  when  a  topological  change 
occurs  to  the  network.  This  protocol  is  source  initiated,  suited  for  a  highly  dynamic 
mobile  networking  environment  and  provides  multiple  routes  for  any  source  destination 
pair.  It  performs  three  basic  functions:  a)  route  creation  b)  route  maintenance  and  c)  route 
erasure.  The  route  creation  and  maintenance  process  establishes  a  DAG  (directed  acyclic 
graph)  between  the  source  and  the  destination  using  a  “height”  metric.  Nodes  are  there 
after  assigned  upstream  or  downstream  based  on  their  relative  “height”  metric  compared 
to  their  neighboring  nodes.  If  a  node  moves  the  DAG  is  broken  and  route  maintenance 
becomes  necessary  to  reestablish  a  DAG  routed  at  the  same  destination.  TORA  is 
dependant  on  a  clock  timer  and  assumes  all  nodes  are  synchronized  to  the  clock.  The 
calculation  of  the  height  metric  is  based  on  the  timing.  This  metric  comprises  of  five 
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elements  namely  a)  logical  time  of  link  failure  b)  unique  ID  of  the  node  that  defined  the 
new  reference  level  c)  reflection  indicator  bit  d)  propagation  ordering  parameter  and  e) 
unique  ID  of  the  node.  The  first  three  elements  collectively  represent  the  reference  level. 
Every  time  a  node  looses  its  last  link  due  to  link  failure  a  new  reference  level  is  defined. 
This  scheme  has  a  potential  for  oscillations  to  occur.  However  such  oscillations  are 
temporary  and  route  convergence  does  occur  finally  as  TORA  uses  inter  nodal 
coordination. 


(4)  (3) 

.  -ii-  Link  Reversal  Link  Failure 


(b) 

Figure  16.  (a)  Route  creation  (b)  Route  maintenance  (From  [2]). 
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4.  Signal  Stability  Routing  (SSR) 

SSR  performs  route  selection  based  on  the  signal  strength  between  nodes  and  on  a 
node’s  location  stability.  SSR  can  be  divided  into  a)  dynamic  routing  protocol  (DRP)  and 
b)  static  routing  protocol  (SRP).  A  signal  stability  table  (SST)  and  a  routing  table  (RT)  is 
maintained  by  the  DRP.  The  SST  contains  records  of  signal  strength  of  neighboring 
nodes  which  are  obtained  periodically  from  beacons  sent  out  by  the  neighbors  at  the  link 
layer.  The  signal  strength  is  categorized  as  either  strong  or  weak  channel.  The  routes 
from  source  to  destination  are  stored  in  the  routing  table.  When  a  packet  is  received  for 
transmission  it  is  processed  in  the  SRP.  The  SRP  looks  for  the  destination  of  the  packet  in 
the  RT  and  then  forwards  them  if  a  route  is  found.  If  no  route  is  found  then  a  route  search 
process  is  initiated  and  route  requests  propagated  through  the  network.  However  the  route 
requests  are  forwarded  to  the  next  hop  only  if  they  are  received  over  strong  channel  and 
have  not  been  processed  previously.  The  destination  returns  the  route  search  packet  that  it 
received  first  as  it  is  most  probably  the  packet  that  has  traveled  the  shortest  path  or  the 
least  congested  path.  The  DRP  then  reverses  the  selected  route  and  sends  a  route  reply 
message  to  the  source.  The  source  then  forwards  the  message  to  the  destination  along  the 
route  specified  in  the  route  reply  message.  Route  search  packets  that  are  received  at  the 
destination  are  assumed  to  have  traveled  the  path  of  the  strongest  signal  links  as  the 
nodes  would  have  been  dropped  if  they  had  arrived  over  a  weak  channel.  However  if  no 
route  message  is  received  at  the  source  within  a  specific  time  out  period  the  source  may 
change  the  preference  field  of  the  header  in  the  route  search  packets  to  indicate  the 
acceptance  of  weak  channels  also.  Link  failure  is  detected  within  the  network  when 
intennediary  nodes  send  error  messages  to  the  source  indicating  the  failure  of  a  channel. 
Under  these  circumstances  another  route  search  process  may  have  to  be  initiated.  There 
after  the  source  sends  a  message  to  erase  the  route  to  all  concerned  nodes. 

5.  Location  Aided  Routing  (LAR) 

LAR  uses  location  information  (via  a  GPS)  to  improve  performance.  LAR  uses  a) 
expected  zone  and  b)  request  zone  to  limit  the  search  for  a  new  route.  LAR  assumes  the 
sender  has  the  knowledge  of  the  destination  and  velocity  before  hand.  The  expected  zone 
is  calculated  based  on  this  infonnation.  The  smallest  triangle  that  includes  the  expected 
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zone  and  the  sender  is  called  the  request  zone.  Nodes  that  do  not  fall  within  the  request 
zone  discard  packets  that  they  receive.  Nodes  that  fall  within  the  request  zone  respond 
with  routes  to  the  destination  if  they  have  any.  LAR  depends  on  GPS  receivers  being  able 
to  be  connected  to  the  sender  and  other  nodes.  However  not  all  devices  can  be  equipped 
with  GPS  receivers  and  in  such  cases  the  scheme  will  not  be  implement  able.  This 
scheme  has  to  overcome  problems  caused  due  to  positional  errors. 


Figure  17.  (a)Concept  of  request  zone  and  expected  zone  in  LAR  (b)  Consideration  of  route 

physical  distance  (From  [2]). 

6.  Power  Aware  Routing  (PAR) 

PAR  advocates: 

1 .  Minimizing  energy  consumed  per  packet 

2.  Minimizing  variance  in  node  power 

3 .  Minimizing  cost  per  packet 

4.  Minimizing  the  maximum  node  cost 

5.  Maximizing  the  time  before  network  is  partitioned 
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This  protocol  prefers  routes  of  nodes  that  have  longer  battery  life. 


Figure  18.  PAR  based  on  remaining  battery  life  (From  [2]). 

7.  Zone  Routing  Protocol  (ZRP) 

ZRP  is  a  hybrid  protocol  that  incorporates  the  principles  of  on  demand  and 
proactive  routing  protocols.  It  consists  of  routing  zones  similar  to  a  cluster  and  every 
node  in  the  cluster  acting  as  both  a  cluster  head  and  a  member  of  the  cluster.  Zones 
comprise  of  a  few  mobile  ad  hoc  nodes  with  one  or  two  hops  and  can  overlap.  A  table 
driven  routing  protocol  is  used  within  the  zone.  It  has  three  sub  protocols  a)  proactive 
(table  driven)  intra  zone  routing  protocol  (IARP)  b)  reactive  inter  zone  routing  protocol 
(IERP)  and  c)  border  cast  resolution  protocol  (BRP).  IARP’s  role  is  to  ensure  that  all 
nodes  within  the  zone  have  a  consisting  routing  table  and  can  be  implemented  using  the 
existing  link  state  or  distance  vector  routing  protocols.  IERP  runs  on  the  border  nodes 
and  requires  them  to  perform  on  demand  routing  to  search  for  routing  infonnation  to 
nodes  outside  the  current  zone.  Broadcasts  are  not  allowed  to  penetrate  into  nodes  within 
other  zones.  When  routes  are  broken  if  the  source  for  the  breakage  is  within  the  zone  it  is 
treated  like  a  change  event  and  an  event  driven  route  update  informs  the  other  nodes 
within  the  zone  of  the  link  failure.  If  the  mobility  is  a  result  of  a  border  node  or  a  node 
outside  the  zone  then  a  route  search  is  to  be  performed  again. 
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Figure  19. 


Hybrid  approach  -  ZRP  (From  [2]). 


V.  AD  HOC  NETWORK  USING  TCP  PROTOCOLS 


A.  INTRODUCTION 

Transmission  control  protocol  (TCP)  being  the  most  popular  and  widely  accepted 
end  to  end  internet  protocol  becomes  an  immediate  choice  for  ad  hoc  networks  as  well. 
However  the  TCP  protocol  cannot  be  used  to  implement  an  ad  hoc  network  without 
making  some  changes.  TCP  provides  reliable  end  to  end  transmission  at  the  transport 
layer  of  the  OSI  stack  ensuring  packets  arrive  in  sequence  at  the  receiver  and  also  ensures 
retransmission  of  lost  packets.  This  protocol  also  provides  flow  and  congestion  control 
functions.  Reliability  is  ensured  by  the  hand  shaking  signals  between  the  sender  and 
receiver.  Sequence  numbers  help  identify  lost  packets  and  also  ensure  in  sequence 
delivery  of  packets.  The  TCP  protocol  employs  a  retransmission  mechanism  that  is 
adaptive  and  capable  of  accommodating  delays  in  the  environment.  This  is  achieved 
using  the  sliding  window  mechanism  of  the  TCP  protocol. 


B.  TCP  FLOW  CONTROL 

TCP  ensures  connection  oriented  service  by  first  establishing  a  virtual  circuit 
connection  (VCC)  between  the  source  and  the  destination.  The  connection  is  established 
hop  by  hop  prior  to  data  transmission.  Every  data  the  source  node  sends  is  acknowledged 
by  the  receiver.  The  transmission  rate  from  the  sender  increases  gradually  with  the  receipt 
of  acknowledgements  from  the  destination.  This  ensures  traffic  regulation  in  accordance 
with  the  congestion  state  and  connection  quality  and  is  known  as  flow  control.  The 
sliding  window  mechanism  allows  the  transmission  of  multiple  packets  before  receiving 
an  acknowledgement.  The  window  size  gradually  opens  up  when  wider 
acknowledgements  are  successfully  received  and  thereby  flow  control  is  exercised  as  the 
sender  will  not  send  packets  unless  the  receiver  responds  with  acknowledgements.  If  the 
receiver  buffer  size  becomes  full  the  receiver  sends  a  small  window  size  advertisement 
forcing  the  sender  to  send  smaller  packets.  In  an  extreme  case  the  receiver  may  stop 
transmissions  from  the  sender  by  sending  a  window  size  of  zero.  TCP  protocol  thereby 
keeps  track  of  the  segments  transmitted  using  the  sequence  numbers  and  provides  flow 
control  using  the  window  size  advertisements  received  from  the  destination. 
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C.  TCP  CONGESTION  CONTROL 

Congestion  control  mechanisms  detect  congestion  through  packet  loss  and  change 
in  round  trip  times  or  through  put.  The  congestion  control  mechanisms  are  either  source 
based  schemes  or  gateway  based  schemes.  Notable  source  based  schemes  include  Slow 
start,  TRI-S,  Dual  and  TCP  Vegas.  Random  early  detection  and  explicit  congestion 
notification  schemes  are  gateway  based  methods.  When  a  connection  is  started  or  when  a 
retransmission  is  started  the  congestion  window  size  is  set  to  one  packet  length.  The 
sender  increases  the  window  size  by  one  packet  size  upon  receipt  of  an  acknowledgement 
until  the  first  sign  of  congestion  is  detected.  Once  the  congestion  is  detected  the  window 
size  is  reduced  by  half  and  a  back  off  takes  place.  The  slow  start  (SS)  process  is  resumed 
again.  Thereby  an  additive  increase  and  a  multiplicative  (back  off)  decrease  policy  is 
employed  to  avoid  congestions.  TCP  congestion  control  consists  of  a)  slow  start  (SS)  b) 
congestion  avoidance  (CA)  and  c)  fast  retransmit/fast  recovery.  At  the  start  of  a 
connection  the  congestion  window  size  is  set  to  one  packet.  Data  of  one  packet  length  is 
sent  and  an  acknowledgement  received.  Now  the  congestion  window  size  is  increased  to 
two  packet  lengths  and  an  acknowledgement  is  expected.  The  increase  in  congestion 
window  size  carries  on  until  congestion  is  detected.  At  that  point  the  congestion  window 
size  is  halved  and  is  called  the  congestion  threshold  size.  The  sender  however  does  not 
transmit  at  the  congestion  threshold  size  but  starts  from  a  more  conservative  congestion 
window  size  of  one  which  is  the  slow  start  up  process  all  over  again.  The  congestion 
window  size  is  again  increased  in  steps  of  one  until  it  reaches  the  congestion  threshold 
size. 


D.  VERSIONS  OF  TCP 

1.  TCP  Reno 

TCP  Reno  employs  SS  and  CA  mechanism.  The  TCP  sender  window  size  is 
increased  until  packet  losses  are  experienced.  The  window  size  is  then  halved  causing  a 
linear  less  gradual  increase  in  packet  transmission.  Consequently  these  additive  increase 
and  multiplicative  decrease  in  window  size  lead  to  periodic  oscillations,  round  trip  delays 
and  queue  lengths.  In  the  original  retransmission  mechanism  of  TCP  the  round  trip  time 
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is  based  on  the  time  elapsed  between  the  instant  when  a  packet  is  sent  and  the  instant  at 
which  an  acknowledgement  is  received.  However  the  introduction  of  a  500ms  interval 
clock  to  calculate  the  RTT  provides  a  coarse  time  interval.  This  coarse  time  interval 
implies  that  the  time  interval  between  sending  a  segment  that  is  lost  and  the  instant  when 
the  time  out  occurs  and  the  segment  is  resent  is  much  longer  than  necessary.  Hence  fast 
retransmission  and  fast  recovery  mechanisms  are  incorporated  by  not  only  retransmitting 
when  the  time  out  occurs  but  also  ensuring  retransmission  when  three  duplicate 
acknowledgements  are  received  from  the  receiver.  Under  this  scheme  a  duplicate 
acknowledgement  is  sent  when  a  receiver  cannot  acknowledge  incoming  new  segments 
due  to  the  loss  of  previous  segments  and  keeps  responding  with  duplicate 
acknowledgements  of  previously  received  packets. 

2.  TCP  Tahoe 

TCP  Tahoe  was  an  early  implementation  that  adapted  the  Go-Back-N  model 
which  used  the  cumulative  positive  acknowledgement  scheme  and  required  a  retransmit 
timer  to  expire  to  retransmit  lost  data.  This  implementation  also  used  the  SS,  CA  and  fast 
retransmits  algorithms.  The  slow  start  algorithm  added  a  congestion  window  size  of  one 
to  the  per  connection  state.  When  a  retransmission  was  necessary  after  a  packet  loss,  the 
congestion  window  size  was  reset  to  one.  Thereafter  on  every  acknowledgement  the 
congestion  window  size  was  increased  by  one/congestion  window  size.  Finally  the  fast 
retransmit  algorithm  monitored  the  duplicate  acknowledgements  for  the  same  TCP 
segment,  inferred  packet  losses  and  started  retransmission  without  waiting  for  the  timer 
to  expire. 


3.  TCP  Vegas 

TCP  Vegas  was  proposed  in  1994  and  is  different  form  TCP  Reno  as  it  uses  a  new 
retransmission  mechanism,  an  improved  congestion  avoidance  mechanism  and  a 
modified  slow  start  scheme.  This  implementation  made  a  more  accurate  detennination  of 
the  round  trip  time  interval  by  recording  the  source  system  clock  each  time  a  segment  is 
sent.  It  calculated  the  RTT  by  recording  the  source  system  clock  time  of  receipt  of  the 

acknowledgement  and  finding  the  difference  between  the  transmit  time  and  the  receipt  of 

37 


acknowledgement.  This  was  compared  to  the  time  out  value  and  a  retransmission  was 
effected  if  the  value  exceeded  the  time  out  value.  TCP  Vegas  could  also  ensure 
retransmission  without  having  to  wait  for  three  duplicate  acknowledgements  when  the 
time  for  the  receipt  of  two  duplicated  acknowledgements  exceeded  the  time  out  for  the 
lost  packet.  This  implementation  limited  the  exponential  growth  only  by  every  other 
RTT.  In  between  RTT  the  congestion  window  stays  fixed  so  as  to  ensure  a  valid 
comparison  between  the  actual  and  expected  rates.  The  expected  rate  was  calculated  by 
Expected  =  Window  Size  /  Base  RTT  where  base  RTT  is  the  minimum  of  all  measured 
round  trip  times  and  generally  corresponded  to  the  time  interval  for  the  first  segment  over 
the  TCP  connection.  The  window  size  corresponded  to  the  current  congestion  window 
size.  The  actual  sending  rate  was  determined  by  dividing  the  number  of  bytes  transmitted 
by  the  sample  RTT.  If  the  difference  between  the  actual  and  expected  values  was  less 
than  a  threshold  (a)  the  congestion  window  size  was  increased  linearly  during  the 
succeeding  RTT.  If  the  difference  was  greater  than  the  threshold  (P)  Vegas  would 
decrease  the  congestion  window  size  linearly  during  the  next  RTT.  No  action  was  taken 
if  the  window  size  was  between  a  and  p. 

4.  TCP  SACK 

TCP  with  selective  acknowledgement  (SACK)  is  an  improvement  over  the 
positive  acknowledgement  with  retransmission  scheme.  In  the  TCP  schemes  seen  so  far 
the  sender  awaits  an  acknowledgement  for  every  packet  sent  before  the  time  out  occurs. 
If  a  time  out  occurs  the  packets  are  retransmitted.  In  such  situations  TCP  sender  learns 
about  a  single  packet  loss  after  a  round  trip  time.  In  selective  acknowledgement  the 
receiver  sends  back  acknowledgement  packets  to  inform  the  sender  that  the  data  has  been 
successfully  received  so  as  to  enable  the  sender  to  retransmit  only  the  missed  segments. 
While  other  packets  received  correctly  are  buffered  in  the  receiver. 

E.  PROBLEMS  WITH  TCP  IN  A  WIRELESS  ENVIRONMENT 

Date  connections  originating  from  mobile  nodes  occur  over  a  wireless  link  to  a 
base  radio  station  and  through  that  radio  station  to  the  destination  server  in  a  wired 
medium.  Congestion  control  in  a  wireless  environment  is  more  complex  because  the  data 
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transmitted  in  a  wireless  environment  are  subject  to  multi  path  fading  and  signal 
jamming.  These  affect  the  calculation  of  round  trip  times  and  the  timely  arrival  of  TCP 
acknowledgement  packets.  Therefore  provisions  have  to  be  made  to  make  the  TCP 
wireless  aware  so  that  it  can  adapt  accordingly  without  affecting  communication 
performance.  In  an  ad  hoc  environment  this  situation  becomes  even  more  complex  when 
due  to  the  mobility  of  a  node  a  route  is  broken  and  a  route  reconstruction  or 
reconfiguration  process  is  initiated.  Under  these  circumstances  the  TCP  sender  is 
unaware  of  the  incident  and  assumes  the  delay  of  arrival  of  an  acknowledgement  as  an 
increase  in  the  round  trip  time  or  as  signs  of  network  congestion.  This  belief  leads  the 
node  to  begin  reducing  its  transmission  window  size  and  the  slow  start  up  mechanism 
which  causes  significant  reduction  in  communication  throughput. 


F.  MODIFICATIONS  TO  TCP  TO  SUPPORT  AD  HOC  NETWORKS 

1.  TCP  Feedback  (TCP-F) 

TCP-F  informed  the  source  of  a  route  disconnection  as  a  result  of  node  mobility. 
This  implementation  was  introduced  in  1998  whereby  a  link  in  a  route  that  is  broken 
informs  the  upstream  nodes  the  disconnection  by  sending  a  route  failure  notification 
(RFN)  message.  This  required  the  introduction  of  a  new  state  in  the  TCP  stack  called  the 
snooze  state.  The  TCP  source  is  required  to  do  the  following  when  it  enters  the  snooze 
state:  a)  stop  transmitting  all  data  packets  (new  data  as  well  as  retransmissions)  b)  freeze 
all  timers,  congestion  window  size  and  other  state  variables  such  as  retransmission  timer 
value  c)  initiate  a  route  failure  timer  to  help  monitor  the  worst  case  route  repair  time  and 
d)  restore  all  timers  and  state  variables  when  a  route  repair  complete  message  is  received. 

2.  TCP-BUS 

This  TCP  principle  deals  with  an  end  to  end  connection  in  an  ad  hoc  wireless 
network  which  has  multiple  wireless  links.  Under  such  circumstances  flow  and 
congestion  control  provided  at  the  source  and  destination  alone  is  insufficient.  Five 
enhancements  have  been  introduced  in  the  TCP-BUS.  They  are  a)  explicit  notification  b) 
extension  of  time  out  values  c)  selective  retransmission  d)  avoidance  of  unnecessary 
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requests  for  fast  transmissions  and  e)  reliable  transmission  of  control  messages.  Explicit 
notifications  differentiate  between  network  congestion  and  route  failure  due  to  mobility. 
Explicit  route  disconnection  notification  (ERDN)  message  is  created  and  sent  back  to  a 
node  to  inform  any  route  disconnection.  When  this  happens  the  source  stops  all  message 
transmission  and  a  route  reconfiguration  process  is  initiated,  which  is  completed  by  the 
generation  of  an  explicit  route  successful  notification  (ERSN)  message.  On  receipt  of  this 
message  data  transmission  is  resumed.  The  extension  of  time  out  values  is  necessary  to 
account  for  route  reconfiguration  or  repair.  Time  out  values  for  buffered  packets  at  the 
source  and  along  the  path  are  doubled.  There  is  another  optional  time  out  value  which 
depends  on  a  variety  of  factors  and  is  under  research.  Retransmission  of  lost  packets 
along  the  path  depends  on  a  time  out  mechanism  in  the  current  TCP  implementation. 
Each  node  in  the  ad  hoc  route  has  a  TCP  layer  built  in  and  therefore  the  time  out  values 
for  buffered  packets  at  these  nodes  are  doubled.  This  results  in  the  time  out  for 
retransmissions  of  packets  being  localized  and  the  source  does  not  have  to  retransmit  all 
the  time.  Retransmission  takes  place  at  every  node  if  required.  The  packets  which  were 
buffered  in  an  ad  hoc  route  prior  to  a  route  disconnection  are  discarded  or  flushed  when 
the  route  disconnection  occurs.  This  would  lead  to  extensive  retransmissions  by  the 
source  node  and  to  avoid  this  condition  the  destination  node  is  required  to  send 
acknowledgement  packets  containing  expected  sequence  numbers  in  order  to  limit  or 
avoid  unnecessary  retransmission.  Route  disconnections  are  notified  using  a  control 
message  sent  to  the  source  node.  However  the  source  node  can  react  only  if  the  control 
message  reaches  it.  When  such  a  message  is  being  sent  intermediary  nodes  are  expected 
also  to  stop  transmitting  their  buffered  packets.  Sensing  if  the  control  message  has  been 
relayed  successfully  by  the  intermediary  nodes  will  ensure  reliable  transmission  of 
control  messages.  When  a  route  repair  is  completed  another  control  message  is 
transmitted  and  this  also  has  to  be  transmitted  reliably  to  the  source  to  ensure  the 
commencement  of  further  transmissions.  The  transmission  of  control  messages  can  be 
achieved  using  any  one  of  the  two  possible  approaches  a)  a  probe  message  is  sent  by  the 
source  to  check  if  a  pivoting  node  has  successfully  acquired  a  new  route  to  the 
destination  b)  every  intermediary  node  sends  an  ERSN  upstream  until  it  receives  data 
packets. 
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VI.  AD  HOC  SERVICE  DISCOVERY 


A.  INTRODUCTION 

After  having  seen  the  differences  in  requirement  at  the  Data,  Network  and 
Transport  Layer  of  the  OSI  stack  in  a  Ad  hoc  environment  in  the  previous  chapters  we 
will  look  at  the  different  requirements  needed  at  the  Application  or  higher  layer  to 
implement  collaborative  services  in  an  Ad  hoc  Network.  Resource  discovery  over  the 
internet  was  a  popular  topic  in  the  past.  Search  engines  evolved  which  performed  this 
service.  However  in  an  ad  hoc  network  there  is  no  standard  existing  for  service  discovery. 
In  this  chapter  we  will  take  a  look  at  what  has  been  done  by  the  IETF  towards  providing 
such  a  service  for  an  ad  hoc  network.  In  1997  service  location  protocol  (SLP)  was 
documented  as  an  RFC  2165.  Let  us  take  a  look  at  what  the  RFC  suggested. 

B.  SERVICE  LOCATION  PROTOCOL  (SLP) 

The  SLP  architecture  requires  a  user,  directory  and  sendee  agents.  As  per  the 
architecture,  user  agents  (UA)  interact  with  directory  agents  (DA)  that  contain  lists  of 
service  agents  (SA).  Services  offered  have  a  life  time  and  DA  keeps  updated  information 
about  the  services  being  provided.  Services  available  are  provided  to  the  UA  using 
advertisements.  The  advertisements  are  messages  that  include  host  address  and  port 
number  of  the  service  provider.  They  are  commonly  known  as  service  access  points.  In 
addition  service  access  information,  service  type  and  attributes  required  are  provided. 

1.  User  Agent 

These  are  software  entities  that  search  for  requested  service.  They  can  serve 
multiple  end  users  and  have  memory  to  cache  service  information  so  as  to  enable  quick 
servicing  of  subsequent  requests.  It  does  not  provide  the  user  access  methods  to  be  used 
but  merely  points  towards  the  service  provider.  Implementation  considerations  require 
the  presence  of  one  user  agent  at  least  per  sub  network. 
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2.  Directory  Agent 

To  help  the  service  location  architecture  to  scale  a  directory  agent  is  used.  In  a 
very  large  network  the  UA  may  receive  thousands  of  replies  about  a  service  it  is 
requesting.  This  could  lead  to  a  lot  of  traffic  in  a  wireless  environment  which  could  result 
in  an  inefficient  use  of  the  wireless  media.  The  DA  helps  alleviate  this  problem  by 
consolidating  all  the  service  advertisement  in  a  cache  and  providing  them  as  a  directory. 
Additionally  the  DAs  can  delineate  user  agents  beyond  a  subnet  from  accessing  certain 
restricted  resources.  For  e.g.,  printer  services  within  a  subnet  can  be  accessed  by  UA 
belonging  to  that  subnet  only.  This  allows  the  creation  of  administrative  domains  and 
limits  the  visibility  of  services. 

3.  Service  Agent 

The  SA  is  the  service  provider  and  advertises  the  available  services  to  the  UA 
directly  or  to  the  DA.  In  a  scenario  where  only  UA  and  SA  exist  service  request  queries 
are  sent  using  a  multicast  message.  When  UA  DA  and  SA  exist  together,  SA 
advertisements  are  registered  with  DA  and  UA  queries  DA  for  the  services  using  unicast 
communication. 

C.  SIMPLE  SERVICE  DISCOVERY  PROTOCOL  (SSDP) 

SSDP,  proposed  by  researchers  of  Microsoft,  was  used  to  discover  resources  in  a 
wired  network.  Service  providers  announce  their  presence  upon  service  creation  and 
clients  access  them  when  desired.  Multicast  communications  are  used  for  both  service 
announcements  and  requests.  Unicast  communication  was  used  to  inform  clients  that  they 
could  use  the  requested  service  by  the  service  provider.  The  service  discovery  process 
occurs  when  a  client  initiates  an  HTTP  UDP  discovery  request  and  sends  it  to  the  SSDP 
multicast  channel/port.  The  service  providers  listen  for  such  multicast  channel/port 
requests  and  respond  with  a  Unicast  HTTP  UDP  message.  SSDP  is  an  even  driven 
protocol  administered  using  the  multicast  address  (239.255.255.250).  New  service 
providers  are  required  to  declare  their  presence  when  they  go  online  and  there  is  no 
requirement  for  any  further  advertisements  until  they  go  offline.  Service  discovery 
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messages  have  a  service  lifetime  specified  in  the  form  of  seconds,  minutes,  days,  weeks, 
months  and  years  and  are  sent  based  on  demand. 

D.  DISTRIBUTED  QUERY  BASED  ARCHITECTURE 

This  architecture  does  not  have  any  service  coordinators.  Clients  locate  service 
providers  directly.  Clients  looking  for  service  locate  service  providers  by  broadcasting 
messages  to  neighboring  nodes.  Servers  that  receive  these  messages  reply  via  a  directed 
broadcast.  It  is  possible  that  two  neighboring  servers  may  provide  the  same  service  and 
the  client  chooses  whichever  server  it  wants.  As  there  are  no  service  coordinators,  this 
architecture  does  not  scale  very  well. 
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VII.  COLLABORATIVE  SERVICES  DEVELOPMENT 

METHODOLOGY 


A.  INTRODUCTION 

Ad  hoc  wireless  networking  is  evolving  in  both  design  of  ad  hoc  routing  protocols 
and  prototype  implementation.  There  are  a  large  number  of  protocols  which  have  been 
suggested  and  a  few  prototypes  have  also  been  implemented  using  the  existing  protocols 
like  HTTP,  TELNET,  FTP  and  TCP/IP.  These  studies  and  experiments  have  provided 
varying  degrees  of  results  on  throughput,  EED  and  RD  time  and  have  thereby 
necessitated  change  in  existing  protocols  to  satisfy  Ad  hoc  environment  needs.  The 
changes  may  be  minor  in  certain  protocols  (such  as  TCP/IP)  and  certain  other  new 
protocols  have  to  be  created  (such  as  SSDP,  SLP  V2)  to  be  able  create  collaborative 
services.  Implementing  ad  hoc  wireless  networks  using  the  current  mobile  computer 
technology,  wireless  adapters  and  Ad  hoc  routing  software  is  feasible  and  the  resulting 
communication  perfonnance  is  acceptable  for  most  data  application.  However, 
collaborative  services  can  be  created  by  fine  tuning  Ad  hoc  routing  protocols  and  creating 
mobile  operating  systems  that  provide  additional  functionality  such  as  SLP.  Currently  ad 
hoc  routing  software  is  written  from  scratch  as  the  existing  mobile  operating  systems  do 
not  cater  for  the  Ad  hoc  routing  functionality.  The  collaborative  chat  service 
implemented  by  this  thesis  demonstrates  the  feasibility  of  building  a  service  using  the 
UDP  protocol  and  multicast  routing  principle.  This  service  caters  for  the  establishment  of 
a  single  cluster  with  a  cluster  head  and  multiple  users  being  able  to  join  and  leave  the 
cluster. 

With  the  recent  exponential  growth  in  the  wireless  technology  and  the  popularity 
of  handheld  devices  there  are  abundant  devices  available  in  the  market.  The  mobile 
devices  that  were  chosen  for  implementation  in  this  thesis  were  those  that  were  readily 
available  in  the  school.  There  are  two  major  options  available  to  develop  the  ad  hoc 
toolkit.  Option  I  was  to  use  a  Palm  Device  which  ran  on  Palm  OS  and  Option  II  was  to 
use  a  Pocket  PC  device  which  ran  on  a  Windows  CE  OS.  In  both  the  options  the  devices 
available  were  WI-FI  enabled.  The  ad  hoc  network  was  to  be  built  using  the  wireless 
802.11  standard  as  this  was  the  most  widely  accepted  successfully  implemented 
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technology  that  supported  the  requirements  of  an  ad  hoc  network.  As  was  discussed  in 
Chapter  II  the  media  access  protocol  requirements  of  an  ad  hoc  network  were  satisfied  to 
a  great  extent  by  the  802.1 1  protocol.  The  routing  and  other  security  requirements  could 
be  built  on  top  of  this  protocol.  The  standard  supported  mobility  within  the  radio  range  of 
the  devices.  The  software  requirements  included  the  choice  of  an  OS  and  then  the  choice 
of  a  development  environment.  The  Microsoft  Windows  CE  OS  offered  the  choice  of 
developing  the  toolkit  using  any  one  of  the  following  environment: 

i)  Embedded  Visual  C++  4.0 

ii)  Embedded  Visual  Basic 

iii)  Net  Compact  Framework  Environment 

The  .Net  Compact  Framework  provided  and  integrated  environment  for 
developing,  debugging  ,  testing  and  deploying  the  embedded  device  software  applications 
where  as  the  other  two  environments  catered  for  the  development  and  debugging 
requirements  but  required  extensive  deployment  procedures  to  be  followed  to  run  the 
applications  developed.  The  .Net  Compact  framework  also  provided  the  flexibility  of 
programming  in  either  Visual  Basic  or  C#. 

The  choice  of  Palm  OS  would  have  entailed  the  choice  of  a  JAVA  development 
environment.  The  resources  available  in  this  environment  are  extensive.  The  major 
compatibility  issues  are  programs  written  for  one  OS  are  not  supported  by  the  other  OS 
and  hence  applications  run  only  in  one  family  of  devices  that  run  on  the  same  OS.  The 
other  issue  is  some  amount  of  backward  incompatibility  is  also  seen  among  the  devices 
that  run  same  OS.  For  the  implementation  planned  as  part  of  this  thesis  I  chose  the  .Net 
Environment  for  development  and  the  Pocket  PC  Environment  for  Deployment.  The 
implementation  was  tested  using  multiple  Pocket  PCs. 


B.  ARCHITECTURE 

The  topology  of  an  ad  hoc  network  keeps  varying  and  the  performance  of  any 
control  algorithm  used  in  the  network  for  purpose  of  scheduling  transmission;  routing  and 
broadcasting  require  adapting  to  these  changes  efficiently.  Topology  management  is 
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achieved  using  either  power  control  or  hierarchical  organization.  Power  Control 
mechanism  base  their  control  on  power  available  on  a  per  node  basis  so  that  one  -  hop 
neighbor  connectivity  is  balanced  and  overall  network  connectivity  is  ensured.  The 
hierarchical  approach  requires  a  subset  of  the  network  nodes  to  serve  as  the  network 
backbone  and  support  the  control  functions.  This  topology  is  called  Clustering  and 
consists  of  choosing  cluster  heads  such  that  each  node  is  associated  with  a  cluster  head. 
Once  elected,  the  cluster  heads  are  connected  with  one  another  directly  or  through 
gateways  so  that  the  union  of  cluster  heads  and  gateways  constitute  a  connected 
backbone.  Cluster  heads  and  Gateways  reduce  the  complexity  of  maintaining  topology 
information  and  simplify  functions  of  routing,  bandwidth  allocation,  channel  access, 
power  control  or  virtual  -  circuit  support.  For  the  clustering  to  be  efficient  and  effective 
the  Cluster  heads  and  Gateways  must  be  within  radio  range  and  as  close  as  possible.  The 
other  important  functionality  is  that  the  nodes  in  the  network  have  to  be  aware  of  the 
other  nodes  that  join  the  network  or  leave  the  network.  Only  then  the  nodes  can  elect 
cluster  heads  and  gateways  from  among  themselves.  This  thesis  implements  a  single  hop 
network  that  consists  of  many  nodes  and  a  single  cluster  head  which  also  acts  as  the 
gateway  and  can  be  used  to  connect  to  other  gateways  in  the  future. 

1.  Node  Discovery  Process 

The  node  discovery  process  is  done  by  the  cluster  head  (Listener  Agent)  which 
listens  for  broadcasts  in  the  network  for  a  specific  Communication  ID.  The  network  is 
assumed  to  consist  of  mobile  nodes  communicating  through  a  common  broadcast  channel 
using  omni-directional  antennae  with  the  same  transmission  range  (In  our  case  Pocket 
PCs  WI-FI  enabled.)  The  Listener  Agent  listens  for  Clients  to  register.  Once  registered 
the  Clients  are  able  to  communicate  to  the  Listener  and  also  to  other  Clients  registered 
with  the  Listener.  The  Listener  is  responsible  to  monitor  the  registration  process  of  clients 
and  also  the  de-registration  process  of  clients.  The  Listener  also  ensures  that  messages 
received  from  a  client  are  broadcast  to  every  client  registered  with  it.  As  the 
implementation  consists  of  a  single  hop  no  routing  is  performed  in  this  implementation. 
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2.  Agent  Module 

The  agent  is  required  to  perform  the  role  of  Listener  or  that  of  a  Client  as  required 
and  has  to  be  built  to  support  both  the  functionality.  The  functionality  of  the  Listener 
requires  the  creation  of  two  threads  one  to  support  the  functionality  of  receiving 
messages  from  the  various  clients  and  the  other  to  transmit  the  messages  received  to  other 
registered  clients.  The  process  of  registration  requires  the  creation  of  a  unique 
communication  ID  which  distinguishes  messages  sent  within  this  network.  The  formation 
of  this  network  would  also  entail  the  creation  of  some  control  messages  to  acknowledge 
receipts  of  message,  process  of  registration,  process  of  de-registration  and  transfer  of 
control  of  the  Listener  to  another  node  when  the  Listener  wants  to  leave  the  network  and 
transfers  the  control  to  another  node.  All  this  is  achieved  by  creating  a  client  that  is 
capable  of  sending  and  receiving  messages.  The  listener  inherits  all  the  functionality  from 
the  client  and  also  implements  additional  functionality  of  distributing  messages  in  the 
network.  This  is  achieved  by  creating  an  additional  thread  running  in  the  background 
which  monitors  a  message  queue  to  see  if  there  is  any  message  available  for  distribution. 
The  node  addresses  to  which  the  distribution  is  to  be  effected  is  stored  in  an  array  list  of 
clients  formed  when  clients  register  with  the  listener.  The  implementation  uses  the  Multi 
Comm  Framework  (.dll  file)  developed  by  Jim  Wilson,  [4]  as  the  implementation  was 
found  more  responsive  and  effective  when  developed  using  the  UDP  datagram.  The 
connectionless  UDP  datagram  was  more  efficient  in  a  wireless  environment  than  the 
connection  oriented  TCP  socket  as  it  was  difficult  to  maintain  the  connection  in  a  mobile 
WI-FI  environment  and  the  connections  had  to  be  reestablished  more  than  once  to  ensure 
transmission.  The  connectionless  approach  required  that  an  additional  retransmission 
mechanism  be  created  whenever  an  acknowledgement  was  not  received  for  all  types  of 
transmission.  This  was  a  small  overhead  and  surmountable  than  overcoming  problems  to 
maintain  connection  in  a  connection  oriented  protocol. 
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VIII.  CONCLUSION 


A.  CONCLUSION 

The  potential  for  developing  applications  in  a  mobile  ad  hoc  network  is  immense 
and  the  experience  these  applications  will  provide  when  deployed  would  entail  them 
being  tenned  as  smart  applications.  These  applications  would  be  aware  of  their 
environment.  Ad  hoc  mobile  applications  combine  the  characteristics  of  neighbor-aware, 
location-aware,  connectivity-aware  and  context-aware  smart  applications  in  varying 
degrees  and  forms.  For  example  a  Context/Location  aware  application  running  on  a 
wearable  computer  could  detect  the  presence  of  a  user  in  a  shopping  mall  and  inform  the 
user  of  the  bargains  being  offered,  new  product  information  and  their  availability  to  help 
him  make  informed  decisions.  Additionally  online-catalogs,  price  comparisons,  delivery 
information  and  other  technical  specifications  can  be  received  and  shown  to  the  user 
making  his  shopping  experience  virtually  different.  The  scope  and  potential  of  such  ad 
hoc  applications  is  generally  left  to  the  reader’s  imagination  as  of  today  as  the  protocols 
and  technology  that  support  ad  hoc  computing  evolves.  But  it  is  only  a  matter  of  time 
when  we  will  have  such  applications  running  of  devices  that  are  portable  (as 
miniaturization  improves),  aware  of  other  devices  (as  device  discovery  and  routing 
protocols  improves)  and  are  context  sensitive  (using  smart  applications).  Pervasive 
computing  transcending  physical  boundaries  and  providing  useful  interactive 
environments  can  be  formed  using  ad  hoc  network  technologies.  Motorola  Piano  Project 
and  UC  Berkeley  Sensor  Networks  (Smart  Dust  Project)  are  next  generation  applications 
that  are  being  studied  in  laboratories.  All  these  are  examples  of  collaborative  services  that 
can  be  built  using  the  existing  protocols  or  by  adapting  new  protocols  that  cater  to  the  Ad 
hoc  requirements. 

B.  FOLLOW-ON  WORK 

The  first  stage  of  the  development  of  an  ad  hoc  network  would  be  creation  of  the 
network  itself  and  testing  applications  that  a  based  of  a  single  hop.  This  would  involve 
the  creation  of  smart  applications  (user  agents).  This  user  agent  must  then  be  aware  of 
other  devices  in  the  neighborhood  and  form  a  directory  of  user  agents.  These  user  agents 
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must  then  be  able  collaborate  and  provide  some  service.  This  thesis  implemented  the 
creation  of  an  agent,  development  of  a  directory  and  establishment  of  a  chat  and  file 
transfer  facility  (service)  among  the  agents.  This  service  was  however  limited  to  a  single 
hop  or  a  single  group  of  user  agents.  Multiple  groups  of  such  agents  must  be  able  to 
communicate  among  themselves  and  that  could  be  the  next  stage  of  this  implementation. 
This  would  require  the  employment  of  any  one  of  the  routing  mechanisms  (protocols) 
discussed  earlier  and  would  require  (listener  agent)  in  this  thesis  provide  an  additional 
facility  of  communicating  with  other  listeners  in  the  vicinity  using  the  routing  mechanism 
devised. 
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APPENDIX 


SOURCE  CODE 


using  System; 
using  System. 10; 
using  System. Drawing; 
using  System. Collections; 
using  System. Windows . Forms; 
using  System. Data; 
using  System. Text; 
using  MultiCommFramework; 
using  System. Net . Sockets; 
using  System. Net; 


namespace  MultiCommFramework 

{ 

III  <summary> 

III  Summary  description  for  Agent. 

Ill  </summary> 

public  class  Agent  :  System. Windows . Forms . Form 

{ 

private  string  user  =  "Chat  User"; 

private  string  conversation  =  "Multiple  User"; 

private  bool  isHost  =  true; 

private  string  current  =  null; 

private  int  clientPort  =  5995; 

private  int  listenerPort  =  5998; 


private  const  string  originalTitle  =  "Client"; 
private  const  string  hostTitle  =  "Host"; 
private 


MultiCommClient  multiComm  =  null; 
Encoding  textEncoding  =  Encoding . UTF8 ; 

#region  Windows  Form  generated  code 


private 

private 

private 

private 

private 

private 

private 

private 

private 

private 

private 

private 

private 

private 

private 

private 

private 

private 


System. Windows . Forms 
System. Windows . Forms 
System. Windows . Forms 
System. Windows . Forms 
System. Windows . Forms 
System. Windows . Forms 
System. Windows . Forms 
System. Windows . Forms 
System. Windows . Forms 
System. Windows . Forms 
System. Windows . Forms 
System. Windows . Forms 
System. Windows . Forms 
System. Windows . Forms 
System. Windows . Forms 
System. Windows . Forms 
System. Windows . Forms 
System. Windows . Forms 
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.  TextBox  txtlnput; 

. TextBox  txtDisplay; 
.Menultem  menuClient; 
.Menultem  menuLeave; 
.Menultem  menuModify; 
.Menultem  menuExit; 

.Menultem  menusetting; 
.Menultem  menuJoin; 

.Menultem  menuUtility; 
.Menultem  menuSend; 

.Menultem  menuUserName; 
.Menultem  menuClientPort; 
.Menultem  menuListener ; 
.Menultem  menuCurrentDir ; 
.Menultem  menuTransmitFile; 
.Menultem  menuCopyText; 
.TextBox  CopyBox; 

.Menultem  menuViewClipBoard; 


private  System. Windows . Forms .Menultem  menuSaveClipBoard; 
private  System. Windows . Forms .Menultem  menuCloseClipBoard; 
private  System. Windows . Forms .Menultem  menuclearDisplay; 
private  Microsoft . WindowsCE . Forms . InputPanel  inputPanel2; 
private  System. Windows . Forms .MainMenu  mainMenul; 

public  Agent ( ) 

{ 

// 

//  Required  for  Windows  Form  Designer  support 
// 

InitializeComponent ( ) ; 

// 

//  TODO:  Add  any  constructor  code  after 
InitializeComponent  call 
// 

} 

III  <summary> 

III  Clean  up  any  resources  being  used. 

Ill  </summary> 

protected  override  void  Dispose (  bool  disposing  ) 

{ 

base . Dispose (  disposing  ); 

} 

#region  Windows  Form  Designer  generated  code 

III  <summary> 

III  Required  method  for  Designer  support  -  do  not  modify 
III  the  contents  of  this  method  with  the  code  editor. 

Ill  </summary> 

private  void  InitializeComponent ( ) 

{ 

this . mainMenul  =  new  System. Windows . Forms .MainMenu () ; 
this . menuSetting  =  new  System. Windows . Forms .Menultem () ; 
this . menuModif y  =  new  System. Windows . Forms .Menultem () ; 
this .menuUserName  =  new  System. Windows . Forms .Menultem () ; 
this .menuClientPort  =  new  System. Windows . Forms .Menultem ( ) 
this . menuListener  =  new  System. Windows . Forms .Menultem () ; 
this .menuclearDisplay  =  new 
System. Windows . Forms .Menultem ( )  ; 

this .menuJoin  =  new  System. Windows . Forms .Menultem () ; 
this .menuLeave  =  new  System. Windows . Forms .Menultem () ; 
this . menuClient  =  new  System. Windows . Forms .Menultem () ; 
this .menuExit  =  new  System. Windows . Forms .Menultem () ; 
this . menuUtility  =  new  System. Windows . Forms .Menultem () ; 
this . menuCurrentDir  =  new  System. Windows . Forms .Menultem ( ) 
this .menuTransmitFile  =  new 
System. Windows . Forms .Menultem ( ) ; 

this .menuCopyText  =  new  System. Windows . Forms .Menultem () ; 

this . menuViewClipBoard  =  new 

System. Windows . Forms .Menultem ( )  ; 

this .menuSaveClipBoard  =  new 

System. Windows . Forms .Menultem ( ) ; 
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this .menuCloseClipBoard  =  new 
System. Windows . Forms .Menultem ( ) ; 

this .menuSend  =  new  System. Windows . Forms .Menultem () ; 
this . txtlnput  =  new  System. Windows . Forms . TextBox () ; 
this . txtDisplay  =  new  System. Windows . Forms . TextBox () ; 
this.CopyBox  =  new  System. Windows . Forms . TextBox () ; 
this . inputPanel2  =  new 

Microsoft . WindowsCE . Forms . Input Panel ( )  ; 

// 

//  mainMenul 

// 

this .mainMenul .Menultems .Add (this .menuSetting) ; 
this .mainMenul .Menultems .Add (this . menuUtility)  ; 
this .mainMenul .Menultems .Add (this .menuSend)  ; 

// 

//  menuSetting 

// 

this .menuSetting .Menultems .Add (this .menuModify)  ; 
this . menuSetting . Menultems .Add (this .menuJoin) ; 
this .menuSetting. Menultems .Add (this .menuLeave) ; 
this . menuSetting . Menultems .Add (this .menuClient) ; 
this .menuSetting. Menultems .Add (this .menuExit)  ; 
this .menuSetting . Text  =  "Setting"; 
this . menuSetting . Click  +=  new 

System. EventHandler (this .menuSetting  Click) ; 

// 

//  menuModify 

// 

this .menuModify .Menultems .Add (this .menuUserName) ; 

this . menuModify . Menultems .Add (this .menuClientPort)  ; 

this . menuModify . Menultems .Add (this . menuListener )  ; 

this .menuModify .Menultems .Add (this .menuclearDisplay) 

this . menuModify . Text  =  "Modify"; 

this .menuModify. Click  +=  new 

System. EventHandler (this .menuModify  Click) ; 

// 

/ /  menuUserName 

// 

this . menuUserName . Text  =  "UserName"; 

this .menuUserName . Click  +=  new 

System. EventHandler (this .menuUserName  Click) ; 

// 

//  menuClientPort 

// 

this .menuClientPort . Text  =  "ClientPort"; 

this . menuClientPort . Click  +=  new 

System. EventHandler (this .menuClientPort  Click) ; 


// 

//  menuListener 

// 
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this . raenuListener . Text  =  "ListenerPort" ; 
this .menuListener . Click  +=  new 

System. EventHandler (this .raenuListener  Click) ; 

// 

//  menuclearDisplay 

// 

this . menuclearDisplay . Text  =  "ClearDisplay" ; 

this .menuclearDisplay. Click  +=  new 

System . EventHandler (this .menuclearDisplay  Click) 

// 

/ /  menuJoin 

// 

this .menuJoin . Text  =  "Join"; 
this . menuJoin . Click  +=  new 

System. EventHandler (this .menuJoin  Click) ; 

// 

/ /  menuLeave 

// 

this .menuLeave . Text  =  "Leave"; 

this . menuLeave . Click  +=  new 

System. EventHandler (this .menuLeave  Click) ; 

// 

//  menuClient 

// 

this .menuClient . Text  =  "Client"; 
this .menuClient . Click  +=  new 

System. EventHandler (this ,menuClient_Click) ; 

// 

/ /  menuExit 

// 

this . menuExit . Text  =  "Exit"; 

this .menuExit . Click  +=  new 

System. EventHandler (this .menuExit  Click) ; 

// 

//  menuUtility 

// 

this .menuUtility .Menultems .Add (this .menuCurrentDir) ; 
this .menuUtility .Menultems .Add (this .menuTransmitFile) ; 
this .menuUtility .Menultems .Add (this .menuCopyText) ; 
this .menuUtility .Menultems .Add (this .menuViewClipBoard) ; 
this .menuUtility .Menultems .Add (this .menuSaveClipBoard) ; 
this .menuUtility .Menultems .Add (this .menuCloseClipBoard) ; 
this .menuUtility . Text  =  "Utilities"; 
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// 

//  menuCurrentDir 

// 

this .menuCurrentDir . Text  =  "CurrentDirList" ; 
this .menuCurrentDir . Click  +=  new 

System. EventHandler (this .menuCurrentDir  Click  1); 

// 

/ /  menuTransmitFile 

// 

this .menuTransmitFile . Text  =  "TransmitTextFile" ; 

this .menuTransmitFile . Click  +=  new 

System. EventHandler (this .menuTransmitFile  Click) ; 

// 

/ /  menuCopyText 

// 

this .menuCopyText . Text  =  "CopyText"; 

this .menuCopyText . Click  +=  new 

System. EventHandler (this .menuCopyText  Click) ; 

// 

//  menuViewClipBoard 

// 

this .menuViewClipBoard. Text  =  "ViewClipBoard" ; 
this .menuViewClipBoard. Click  +=  new 

System. EventHandler (this .menuViewClipBoard  Click  1); 

// 

//  menuSaveClipBoard 

// 

this .menuSaveClipBoard. Text  =  "SaveClipBoard" ; 

this .menuSaveClipBoard. Click  +=  new 

System. EventHandler (this .menuSaveClipBoard  Click) ; 

// 

//  menuCloseClipBoard 

// 

this .menuCloseClipBoard. Text  =  "CloseClipBoard" ; 

this .menuCloseClipBoard. Click  +=  new 

System. EventHandler (this .menuCloseClipBoard  Click) ; 

// 

/ /  menuSend 

// 

this .menuSend. Text  =  "Send"; 

this .menuSend. Click  +=  new 

System. EventHandler (this .menuSend  Click) ; 

// 

//  txtlnput 

// 

this . txtlnput . Location  =  new  System. Drawing . Point ( 8 , 
8); 

this . txtlnput . Size  =  new  System. Drawing . Size (224 , 
22); 
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this . txtlnput . Text 


II  II  . 


// 

//  txtDisplay 

// 

this . txtDisplay . Location  =  new 
System. Drawing . Point ( 7 ,  44); 
this . txtDisplay . Multiline  =  true; 
this . txtDisplay . Readonly  =  true; 
this . txtDisplay . ScrollBars  = 

System. Windows . Forms . ScrollBars . Both; 

this . txtDisplay . Size  =  new  System. Drawing . Size (22  4  , 

208)  ; 

this . txtDisplay . Text  = 

// 

/ /  CopyBox 

// 

this . CopyBox . Location  =  new  System. Drawing . Point ( 17 , 
56)  ; 

this . CopyBox .Multiline  =  true; 
this . CopyBox . ScrollBars  = 

System. Windows . Forms . ScrollBars . Both; 

this . CopyBox . Size  =  new  System. Drawing . Size ( 1 91 , 

184); 

this . CopyBox . Text  = 

this . CopyBox .Visible  =  false; 

// 

/ /  Agent 

// 

this . ClientSize  =  new  System. Drawing . Size (24 0 ,  264); 

this . Controls .Add (this . txtlnput) ; 

this . Controls .Add (this . CopyBox) ; 

this . Controls .Add (this . txtDisplay) ; 

this. Menu  =  this .mainMenul; 

this. Text  =  "Collab  Agent"; 


} 

#endregion 
III  <summary> 

III  The  main  entry  point  for  the  application. 
Ill  </summary> 

static  void  Main() 

{ 

Application . Run (new  Agent () ); 

} 

#endregion 
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#region  MultiComm  Management 

III  <summary> 

III  Create  an  instance  of  the  MultiComm  object. 

Ill  The  exact  object  (Client  or  Listener)  is  determined 
III  by  the  Host  choice  in  the  option  dialog. 

Ill  If  host  is  checked,  the  Listener  is  created 
III  otherwise  client 

III  The  only  difference  from  the  program  standpoint 
III  between  client  and  listener  is  in  the  initialization, 
III  the  rest  of  the  program  is  unaffected 
III  </ summary> 

private  void  CreateMultiComm ( ) 

{ 

if  (_isHost) 

multiComm  =  CreateMultiCommListener () ; 

else 

multiComm  =  CreateMultiCommClient ( ) ; 

multiComm . OnReceive  +=  new 
ReceiveEventHandler (  multiComm  OnReceive); 

multiComm. OnTerminate  +=  new 
TerminateEventHandler (  multiComm  OnTerminate); 

} 

III  <summary> 

III  Create  client  object 
III  </summary> 

III  <returns></returns> 

private  MultiCommClient  CreateMultiCommClient ( ) 

{ 

MultiCommClient  client  =  new 

MultiCommClient (  conversation,  clientPort) ; 

client . OnJoined  +=  new 
JoinedEventHandler (client  OnJoined) ; 
client . Start ( ) ; 

client . SendlnviteRequest (  listenerPort) ; 
current  =  originalTitle; 

return  client; 

} 

III  <summary> 

III  Create  instance  of  a  listener  and  attach  to  the 
III  relevent  events 

III  Returns  client  because  all  ongoing  behaivior  is  tracked 

as  client 

III  </summary> 

III  <returns></returns> 

private  MultiCommClient  CreateMultiCommListener ( ) 

{ 
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clientPort, 


MultiCommListener  listener  =  new 
MultiCommListener (  conversation, 
_listenerPort) ; 

listener . OnJoined  +=  new 
JoinedEventHandler ( listener  OnJoined) ; 
listener . OnLeave  +=  new 
LeaveEventHandler ( listener  OnLeave) ; 
listener . Start  ( ) ; 
listener . Sendlnvitation  ( ) ; 
current  =  hostTitle; 

return  listener; 


III  <summary> 

III  Shutdown  the  current  MultiComm  object 

III  </summary> 

private  void  StopMultiComm ( ) 

{ 

if  (  multiComm  !=  null) 

{ 

if  (!  isHost  &&  multiComm. IsInConversation) 

{ 

SendMessage (_user  +  "  has  left"); 
System. Threading . Thread . Sleep (100) ; 

//  give  message  time  to  send 

} 

multiComm . Stop ( ) ; 
multiComm  =  null; 

} 

UpdateDisplay ( "You  have  left  the  conversation"); 


#endregion 


#region  MultiComm  Event  Handlers 

III  <summary> 

III  Fired  by  Listener  (Host)  when  a  client  joins  the 

conversation 

III  </summary> 

III  <param  name=" sender " ></param> 

III  <param  name=" e " >< / par am> 

private  void  listener  OnJoined (obj ect  sender, 
JoinedEventArgs  e) 

{ 

DoUpdateDi splay Invoke (string . Format ( "Connected :  { 0 } " , 

e . ipMember ) ) ; 

} 
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Ill  <summary> 

III  Fired  by  Listener  (Host)  when  a  client  leaves  the 

conversation 

III  </summary> 

III  <param  name=" sender" ></param> 

III  <param  narae=" e " >< / par am> 

private  void  listener  OnLeave (object  sender,  LeaveEventArgs 
e) 

{ 

DoUpdateDi splay Invoke (string . Format ( "Disconnected : 

{ 0 } " ,  e . ipMember ) ) ; 

} 

III  <summary> 

III  Fired  by  client  when  the  Listener  (Host)  acknowledges  a 
III  request  to  join  the  conversation 
III  </summary> 

III  <param  name=" sender" ></parara> 

III  <param  name="e"X/param> 

private  void  client  OnJoined (obj ect  sender,  JoinedEventArgs 
e) 

{ 

DoUpdateDisplaylnvoke ( "You  have  joined:  "  + 
conversation)  ; 

SendMessage (_user  +  "  has  joined"); 

} 

III  <summary> 

III  Fired  each  time  a  conversation  message  is  received 
III  </summary> 

III  <param  name=" sender" ></param> 

III  <param  name="e"X/param> 

private  void  multiComm  OnReceive (object  sender, 
ReceiveEventArgs  e) 

{ 

DoUpdateDisplaylnvoke (  textEncoding . GetString (e . dataBuf fer , 
0,  e . dataBuf fer . Length) ) ; 

} 

III  <summary> 

III  Fired  when  the  Listener  (Host)  terminates  the 

conversation 

III  </summary> 

III  <param  name="sender"x/param> 

III  <param  name="e"X/param> 

private  void  multiComm  OnTerminate ( ob j ect  sender, 
TerminateEventArgs  e) 

{ 

DoUpdateDisplaylnvoke ( "Host  has  terminated  conversation"); 

} 

#endregion 
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#region  Message  Sending 

III  <summary> 

III  Do  Actual  send  of  a  message  to  conversation 

participants 

III  </summary> 

III  <param  name= "mess age ">< /par am> 
private  void  SendMessage ( string  message) 

{ 

if  (  multiComm  !=  null) 

multiComm. Send (  textEncoding . GetBytes (message) ) ; 
else 

MessageBox . Show ( "Must  first  join  a  conversation 
(Conversation/ Join) ") ; 

} 

III  <summary> 

III  Initiate  message  send 
III  </summary> 

III  <param  name="sender"x/param> 

III  <param  name="e"X/param> 

private  void  mnuSend  Click(object  sender.  System . EventArgs 
e) 

{ 

string  message  =  user  +  "  +  txtlnput . Text; 

UpdateDisplay (message) ; 

SendMessage (message)  ; 
txtlnput . Text  =  string . Empty; 

} 

#endregion 

#region  Display  Management 

III  <summary> 

III  Add  a  message  to  txtChatDisplay 

III  Handle  details  of  scrolling  text  into  view 

III  This  also  triggers  an  evaluation  of  available  menu 

selections.  This 

III  is  a  somewhat  inefficient  place  to  do  it  but  simplifies 
the  code  by 

III  providing  single  point  for  modification  for  menu 
selections . 

Ill  </summary> 

III  <param  name="displayText"X/param> 
private  void  UpdateDisplay ( string  displayText) 

{ 

string  linePrefix  =  txtDisplay . Text . Length  ==  0  ? 

"»"  :  "\r\n»"  ; 

txtDisplay . Text  +=  linePrefix  +  displayText; 
PositionChatDisplay ( ) ; 


} 
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//  Helpers  to  transfer  control  to  UI  thread  for  display 
updates 

EventHandler  updateDisplaylnvoker  =  null; 
string  displayText  =  null; 

III  <summary> 

III  Do  the  work  to  place  the  display  text  in  a  member 
variable 

III  then  transfer  control  to  the  UI  thread 
III  </summary> 

III  <param  name="displayText"X/param> 

private  void  DoUpdateDisplaylnvoke ( string  displayText) 

{ 

if  (  updateDisplaylnvoker  ==  null) 
updateDisplaylnvoker  =  new 
EventHandler (UpdateDisplaylnvoke) ; 

displayText  =  displayText; 
txtDisplay . Invoke (  updateDisplaylnvoker) ; 

} 

III  <summary> 

III  Do  the  actual  transfer  to  the  UI  thread  then  display 
the  message 
III  </summary> 

III  <param  name="sender"X/param> 

III  <param  name="e"X/param> 

private  void  UpdateDisplaylnvoke (obj ect  sender,  EventArgs 
e) 

{ 

UpdateDisplay (_displayText) ; 

} 

III  <summary> 

III  Place  a  help  message  in  the  txtChatlnput  and  highlight 
to  be  overwritten. 

Ill  Useful  to  display  help  message  w/o  requireing  extra 
screen  real  estate 
III  </summary> 

III  <param  name="displayText"X/param> 

public  void  DisplayHelpMessage ( long  t2,DateTime  t3, string 
t4 ) 

{ 

string  linePref  =  txtDisplay . Text . Length  ==  0  ?  ">>" 
:  "\r\n»"  ; 

txtDisplay . Text  +=  linePref+t2  +  "  "  +t3  +"  "+  t4; 

/ / txtDisplay . Select All ( ) ; 

PositionChatDisplay ( ) ; 

} 


III  <summary> 

III  Do  the  details  of  scrolling  a  display  message  into  view 
III  </ summary> 

private  void  PositionChatDisplay ( ) 

{ 

txtDisplay. Select (txtDisplay. Text . Length,  0) ; 
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txt Display . ScrollToCaret ( ) ; 

} 

III  <summary> 

III  Do  the  details  of  realigning  the  screen  when  the  input 
panel  (SIP) 

III  is  shown/hiddent 
III  </summary> 

III  <param  name="sender"x/param> 

III  <param  name="e"X/param> 

private  void  inputPanell  EnabledChanged (obj ect  sender. 
System . EventArgs  e) 

{ 

int  screenBottom  =  inputPanel2 . VisibleDesktop . Height; 
if  (!  inputPanel2 . Enabled) 

screenBottom  -=  statBarAdjustment; 

txtlnput.Top  =  screenBottom  -  txtlnput . Height  +  1; 
txtDisplay . Height  =  txtlnput.Top  +  1; 

PositionChatDisplay ( ) ; 

} 

III  <summary> 

III  Adjustment  for  difference  in  VisibleDesktop  property  of 
InputPanel 

III  when  InputPanel  is  not  visible 
III  </summary> 

const  int  statBarAdjustment  =  26; 

#endregion 

#region  Menu  Handling 

III  <summary> 

III  Switch  between  client/listener . 

Ill  For  a  client,  switches  to  listener,  changes  menuname 
client 

III  For  a  listener,  switches  to  client,  changes  menuname 

listener 

III  </summary> 

III  <param  name="  sender" X/param> 

III  <param  name="e"X/param> 

private  void  menuClient  Click (object  sender. 

System . EventArgs  e) 

{ 

if  (current  ==  null) 

{ 

if (menuClient . Text  ==  "Client") 

{ 

_isHost  =  false; 
menuClient . Text  =  "Host"; 


_isHost  =  true; 
menuClient . Text  = 
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} 

else 

{ 


Client" ; 


} 

} 

else 

{ 

string  displayMessagel  =  "You  have  to  leave  the 
conversation  to  change"; 

UpdateDisplay (displayMessagel ) ; 

} 


} 

III  <summary> 

III  Leave  the  current  conversation. 

Ill  For  a  client,  notifies  listener  then  shutsdown 
III  For  a  listener,  notifies  all  clients  then  terminates 
the  conversation 
III  </summary> 

III  <param  name=" sender" ></parara> 

III  <param  name="e"X/param> 

private  void  menuLeave_Click (object  sender. 

System . EventArgs  e) 

{ 

Cursor  originalCursor  =  Cursor . Current; 

Cursor . Current  =  Cursors . WaitCursor  ; 

if  (  multiComm. IsInConversation) 

SendMessage (_user  +  "  has  left"); 
string  displayMessage  =  multiComm. Mode  == 
MultiCommMode . Listener  ?  "Terminating  conversation"  : 
"Leaving  conversation"; 

StopMultiComm ( ) ; 
current  =  null; 

UpdateDisplay (displayMessage) ; 

Cursor . Current  =  originalCursor; 

} 

III  <summary> 

III  Join  the  current  conversation. 

Ill  For  a  client  this  will  start  the  MultiCommClient  and 
then  request 

III  an  invitation  for  the  conversation 

III  For  a  listener,  will  start  a  MultiCommListener  (stored 
as  a  client) 

III  and  then  broadcast  an  invitation  to  join  the 

conversation 

III  </summary> 

III  <param  name="sender"X/param> 

III  <param  name="e"X/param> 

private  void  menuJoin  Click (object  sender.  System. EventArgs 
e) 

{ 

Cursor  originalCursor  =  Cursor . Current; 

Cursor . Current  =  Cursors . WaitCursor  ; 


CreateMultiComm ( ) ; 

63 


//  DisplayHelpMessage ( "<Type  message  here  then  tap 
send>" ) ; 

string  displayMessage  =  multiComm.Mode  == 
MultiCommMode . Listener  ?  "Attempting  to  locate 
available  clients..."  : 

"Attempting  to  locate  host..."; 

UpdateDisplay (displayMessage)  ; 

Cursor . Current  =  originalCursor ; 

} 

III  <summary> 

III  Terminate  the  MultiComm  if  running  then  exit 
III  </summary> 

III  <param  name="sender"x/param> 

III  <param  name="e"X/param> 

private  void  menuExit  Click (object  sender.  System. EventArgs 
e) 

{ 

StopMultiComm ( ) ; 
this . Close ( ) ; 

} 


III  <summary> 

III  To  change  username  that  is  displayed  with  messages 
III  </summary> 

III  <param  name="sender"X/param> 

III  <param  name=" e " >< / par am> 

private  void  menuUserName  Click (object  sender. 

System . EventArgs  e) 

{ 

user  =  txtlnput . Text; 
txtlnput . Text  =  string . Empty; 

} 

III  <summary> 

III  To  change  client  port  number 
III  </summary> 

III  <param  name="sender"x/param> 

III  <param  name="e"X/param> 

private  void  menuClientPort  Click (object  sender. 

System . EventArgs  e) 

{ 

clientPort  =  GetPortValue (txtlnput . Text) ; 
txtlnput . Text  =  string . Empty; 

} 

III  <summary> 

III  To  change  Listener  Port  Number 
III  </summary> 

III  <param  name="  sender" X/param> 

III  <param  name="e"X/param> 

private  void  menuListener  Click (object  sender. 

System . EventArgs  e) 

{ 

listenerPort  =  GetPortValue (txtlnput . Text) ; 
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} 


txtlnput . Text  =  string .Empty; 


III  <summary> 

III  Helper  method  to  extract  the  Port  value  from  the 
Options  form 
III  </summary> 

III  <param  name="portAsString"X/param> 

III  <returns></returns> 

private  int  GetPortValue ( string  portAsString) 

{ 

int  port  =  0; 

if  (portAsString . Trim ( )  !=  string . Empty) 

port  =  int . Parse (portAsString) ; 

return  port; 

} 

III  <summary> 

III  Initiate  message  send 
III  </summary> 

III  <param  name="sender"X/param> 

III  <param  name="e"X/param> 

private  void  menuSend  Click (object  sender.  System. EventArgs 
e) 

{ 

string  message  =  user  +  "  +  txtlnput . Text; 

UpdateDisplay (message) ; 

SendMessage (message) ; 
txtlnput . Text  =  string . Empty; 

} 


III  <summary> 

III  Display  current  directory  listing 
III  </summary> 

III  <param  name="  sender" X/param> 

III  <param  name="e"X/param> 

private  void  menuCurrentDir  Click  1 (object  sender. 
System . EventArgs  e) 

{ 

DirList ( this ) ; 

txtlnput . Text  =  string . Empty; 
PositionChatDisplay ( ) ; 

} 


III  <summary> 

III  To  Transmit  text  files 
III  </summary> 

III  <param  name="  sender" x/param> 

III  <param  name=" e " >< / par am> 

private  void  menuTransmitFile  Click (object  sender. 
System . EventArgs  e) 

{ 

OpenFileDialog  dig  =  new  OpenFileDialog () ; 
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dig. Filter  =  "All  Files  (*.*) | * . * | Text  Files 
(* . txt) | * . txt" ; 
dig . InitialDirectory  = 

if  (dig . ShowDialog ( )  ==  DialogResult . OK) 

{ 

this . txtlnput . Text  =  dlg.FileName; 
MessageBox . Show (dig . FileName) ; 
PositionChatDisplay ( ) ; 

FileRead ( this ) ; 

} 

txtlnput . Text  =  string . Empty; 


} 

III  <summary> 

III  Copy  selected  text  in  the  display  to  clipboard 
III  </summary> 

III  <param  name="sender"x/param> 

III  <param  name="e"X/param> 

private  void  menuCopyText  Click (object  sender. 

System . EventArgs  e) 

{ 

//  Ensure  that  text  is  selected  in  the  text  box. 
if  (txtDisplay . SelectedText  !=  "") 

CopyBox . Text  +=  txtDisplay . SelectedText; 


} 

III  <summary> 

III  To  view  contents  of  clipboard 
III  </summary> 

III  <param  name="sender"X/param> 

III  <param  name=" e " >< / par am> 

private  void  menuViewClipBoard_Click  1 (object  sender. 
System . EventArgs  e) 

{ 

CopyBox . BringToFront ( ) ; 

CopyBox .Visible  =  true; 

} 


III  <summary> 

III  To  save  contents  of  clipboard 
III  </summary> 

III  <param  name="sender"X/param> 

III  <param  name="e"X/param> 

private  void  menuSaveClipBoard  Click (object  sender. 
System . EventArgs  e) 

{ 


SaveFileDialog  dig  =  new  SaveFileDialog () ; 
dig. Filter  =  "Text  File |*. txt"; 
dlg.FileName  =  "user.txt"; 
dig . InitialDirectory  =  "\\My  Documents"; 
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if  (dig . ShowDialog ( )  ==  DialogResult . OK) 

{ 

MessageBox . Show (dig . FileName) ; 
StreamWriter  sw  =  new 
StreamWriter (dig. FileName,  false) ; 
sw . Write ( this . CopyBox . Text)  ; 
sw . Close  ( ) ; 

} 

txtlnput . Text  =  string . Empty; 

} 

III  <summary> 

III  To  close  clipboard 
III  </summary> 

III  <param  name="sender"x/param> 

III  <param  name="e"X/param> 

private  void  menuCloseClipBoard  Click (object  sender. 
System . EventArgs  e) 

{ 

CopyBox . SendToBack ( ) ; 

CopyBox .Visible  =  false; 

} 

III  <summary> 

III 

III  </summary> 

III  <param  name="  sender" X/param> 

III  <param  name="e"X/param> 

private  void  menuModify  Click (object  sender. 

System . EventArgs  e) 

{ 

} 

III  <summary> 

III  To  clear  display  area 
III  </summary> 

III  <param  name="  sender" X/param> 

III  <param  name="e"X/param> 

private  void  menuclearDisplay  Click (object  sender. 
System . EventArgs  e) 

{ 

txtDisplay . Text  =  string . Empty; 

} 

III  <summary> 

III 

III  </summary> 

III  <param  name="  sender" X/param> 

III  <param  name="e"X/param> 

private  void  menuSetting  Click (object  sender. 

System . EventArgs  e) 

{ 
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} 


#endregion 
#region  Utilities 

III  <summary> 

III  Function  to  display  contents  of  current  directory 
III  </summary> 

III  <param  name="sender"X/parara> 

public  static  void  DirList (Agent  sender) 

{ 

Directorylnf o  dir; 

if ( sender . txtlnput . Text  !=  string . Empty) 

dir  =  new  Directorylnf o ( sender . txtlnput . Text ) ; 

else 

dir  =  new  Directorylnf o (".") ; 

try 

{ 

foreach  (Filelnfo  f  in  dir . GetFiles ("*.*") ) 

{ 

String  name  =  f.FullName; 
long  size  =  f. Length; 

DateTime  creationTime  =  f . CreationTime; 
sender . DisplayHelpMessage (size, creationTi 
me,  name) ; 

} 

} 

catch  (Exception  e) 

{ 

sender . UpdateDisplay ( "The  directory  has  no 
files/could  not  be  read: "+e) ; 

} 

} 


III  <summary> 

III  Function  to  read  and  transfer  text  file 
III  </summary> 

III  <param  name="sender"x/param> 
public  static  void  FileRead (Agent  sender) 

{ 

string  fileName  =  sender . txtlnput . Text; 
try 
{ 

/ /  Create  an  instance  of  StreamReader  to  read 
from  a  file. 

//  The  using  statement  also  closes  the 
StreamReader . 

using  (StreamReader  sr  =  new 
StreamReader (fileName) ) 

{ 

String  line; 

//  Read  and  display  lines  from  the  file 
until  the  end  of 
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//  the  file  is  reached. 

while  ((line  =  sr . ReadLine ( ) )  !=  null) 

{ 

sender. SendMessage (line) ; 
sender . UpdateDisplay (line) ; 

} 

} 

} 

catch  (Exception  e) 

{ 

//  Let  the  user  know  what  went  wrong, 
sender . UpdateDisplay ( "The  file  could  not  be 
read : " ) ; 

sender . UpdateDisplay (e .Message) ; 

} 

} 

III  <summary> 

III  Function  to  save  contents  from  clipboard  to  a  file 
III  </summary> 

III  <param  name=" sender" ></param> 

III  <param  name=" e " >< / par am> 

public  static  void  FileWrite (Agent  sender) 

{ 

string  path  =  Ssender . txtlnput . Text; 

//  Delete  the  file  if  it  exists, 
if  (File . Exists (path) ) 

{ 

File . Delete (path) ; 

} 

//  Create  the  file. 

using  (FileStream  fs  =  File . Create (path,  1048576)) 

{ 

Byte [ ]  info  =  new 

UTF 8 Encoding (true) . GetBytes ( sender . CopyBox . Text 

)  ; 

//  Add  some  information  to  the  file, 
fs .Write (info,  0,  inf o . Length) ; 

} 

} 


#endregion 


} 


} 
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